Here are some ways to make millions and not pay taxes.
Many companies pay their CEO's a $1 nominal salary. The company then takes out a $10M life insurance policy on the CEO. The CEO "borrows" money from the life insurance with a promise to pay it back later. The company forgives any money borrowed against the policy.
A company gives may perks to the CEO in lieu of a salary. (e.g. - free vacation with use of company jet, free use of mansion owned by company, free use of car owned by company, etc...) CEO effectively lives a lavish lifestyle without having to pay for it himself. The company pays the CEO in stocks and options that vest later so CEO can delay taxes on those while living quite comfortably.
The company is incorporated in a foreign nation, and pays the CEO a big salary in that nation's currency. CEO keeps salary in offshore bank account.
Anyhow, I think that the *actual* costs of overseas labor are going to start getting serious press soon as well, so hopefully that'll discourage the flava-of-the-month pointy hairs from shipping our work overseas, but I want a backup plan in case....
Outsource companies in India talk about how they cost only 20% of what US-based companies pay for software development. But, actual costs are closer to 80%. If anybody in your company starts talking about outsourcing, give them some hints from somebody who has been to India, and seen what it is like: Think Twice, and Don't Do It!
It takes a while to bring the Indian developers up to speed on the problem domain. It is one thing to know how to make software, but another to know how to make software to solve specific problems. It can take a year or more to transfer that knowledge for complex projects. So, during that time, US-Corp is paying for both its own developers, and the over seas developers. And they have to pay to bring those people over here or over there for training.
Many outsource companies have been known to get contracts to write software, and then go out and hire a dozen people. (Of course, they said up front to potential customers that they had the skills and resources.) I have met many really smart software designers and coders from India, but I have also met many whose only experience is that they read a book called: "Teach Yourself VB in 21 Days!" When you hire somebody for your own company, you can ask tough interview questions to determine the person's skill level. But, when you outsource to anywhere, even in the US, you might not get a chance to learn the skill level of whoever touches the source code. Sure, the company might let you talk to their smartest guys, but you won't know who is writing your source code the next day.
Will you ever get a chance to bring the code home? Maybe. Maybe not. Check your contract with the outsource company before you sign it. Even if they do share the source code with you, they may not want you to touch it yourself. Doing that can invalidate the contract and you have to pay their fees for breaking the contract. And too many PHB's think there is no need to bring the code home, if it can all be done over there. Try talking to a PHB who says: "All we need is the product, not any source code."
In many parts of India, basic utility infrastructure is just not up to American standards. This includes somewhat modern cities like Bangalore and Hyderabad where a lot of software is made. When I was in India, the power just simply went out occasionally. Sections of the city lost power for a few minutes or few hours. People got used to it.
One US corporate executive (won't say who) went over there to interview several companies for offshore software development. The lights went out 4 times during the first hour of the interview. The hosts politely explained that they have battery backups and use laptops with spare batteries. Needless to say, the exec was just not impressed. There was no deal.
I was riding in a taxi (one of those cute little "Amby" cars) and got stopped in one of those traffic jams that occur every few minutes. (Nobody obeys traffic rules consistently there, so traffic jams are just part of the overall experience.) People got used to it. Well, while waiting, I asked the driver about this unfinished bridge that partly crossed the highway. It looked like a highway entrance ramp where the lower part was about 10 feet up, then went for 50 feet, and the upper end just ended in an abrupt dropoff. No road connected to it, although if you extended it, the lower end would intersect the street eventually. It had been there a few years, with graffiti and chipped concrete. Was definately not new construction that had temporarily stopped.
The taxi driver said the city wanted to relieve traffic jams, and decided to make connection from this street over to another street a couple of kilometers away. The connection would be raised t
Yes, you can use simple templates with procedural programming. In that sense, knowledge of OOP is not needed to use templates. But, there are ways in which templates make OOP easier.
Templates can be combined nicely with several design patterns, such as observer, visitor, factory, and iterator. Template base classes for each of these design patterns can provide the common behaviors and implementations of these design patterns.
In addition to augmenting traditional OOP, templated classes can still have a lot of OOP-like properties. The classic examples here are in the STL. If we list the basic features of OOP, our list would include: Abstraction, Polymorphism, Inheritance, and Encapsulation.
The STL classes provide abstract interfaces into containers, algorithms, and iterators. The functors do provide a type of polymorphism through both templates. Several containers provide polymorphism through operator overloading. You can write classes to inherit from C++ containers and iterators, but that has various problems and issues with it. And they encapsulate the implementation details quite well. (e.g. - You don't have to worry about the mechanics of balancing red-black trees when you use std::map and std::set.)
You also need a destructor that walks the vector and calls delete() on each pointer-to-void.
Calling delete or delete[] on a void pointer is not safe. A void pointer is opaque, and so how would the compiler know which delete function to call? Each class can have its own delete and delete [] operators. You can get around this problem by casting the void pointer to the original type before deleting it.
If you don't have delete and delete [] operators for your classes, but always use the global delete and delete [] operators, then this is less of a problem. But, you still have the problem of calling the correct destructor - which is not available through a void pointer.
The STL Standard requires that each container destruct its elements when the container is destroyed, or the element is removed. If the container elements are objects, they are safely destructed. If they are primitives or pointers, then they have no destructors anyway.
If you need a container of pointers, then how about having a container of smart pointers instead? The smart pointers are objects and get destructed automatically. When it gets destructed, it can delete the object it points to, decrement a ref-count, or do whatever else it supposed to. A nice side effect is that you no longer need the unsafe cast to a void pointer.
It will probably become more difficult for Joe Coder to just submit a patch to fix a bug. At worst, a lengthy background check will become required to verify that he hasn't worked on something similar for a corporation. At best, he'll have to complete some paperwork before he gains committer status.
That will only address future contributions. What about past contributions?
From the article:
This raises interesting succession questions. If a Linux contributor were hit by a bus tomorrow, his or her copyright would be part of their estate and could potentially be inherited by antagonistic outsiders more interested in the fast buck than in community-based software. Similar succession issues surround Torvalds' ownership of the Linux trademark.
Have any contributions been copyrighted? And if there are any copyrighted parts of Linux, it should be easy to excise and replace that section of code.
The outcome is obvious: After SCO loses the lawsuit, they will owe IBM and RedHat millions. (And that says nothing about all the possible lawsuits they are begging for.) They are going into bankruptcy with a vengeance.
And after their stock price peaks, the investors will sell off and leave them to die.
It has already been mentioned in an earlier post that one possible outcome is that contributors to Linux will have to acknowledge their work as original. I would hate to see that happen, but it may be necessary to protect Linux distrubutors from lawsuits.
Has anybody gone through existing Linux source code and found anything proprietary? This is a tedious task, and very much after the fact. But, it could protect against future lawsuits.
Tigertigr, burning bright in the forests of the night, what mortal hand or eye can frame thy fearful symmetry?
Tigertigr, I agree with you that a simulated world is always inferior to the real thing. This brings the question of whether inhabitants of the matrix should be able to discover imperfections. The matrix creators can't model the real world in all details correctly all the time. Perhaps an astute observer within the matrix can catch the matrix AI in the act of omission, and find a contradiction that shows the matrix world is too imperfect to be real.
The movie hinted at some imperfections, ESP, angels, and ghosts, but people inside the matrix interpreted experiences with ESP, angels, and ghosts within their own belief systems. Lots of New-Agers unthinkingly accept ESP, and many participants in traditional religions accept angels. These kinds of imperfections do not cause people to doubt their own reality. So, let's talk about a deeper imperfection, beyond the realm of what is easily observed by humans in everyday life.
Can any matrix imperfection be objectively and repeatedly observed - or even produced at will? As objective phenomenon, they are less likely to be unthinkingly incorporated into a religion or any other aggregate belief system. Instead, as measurable and testable phenomenon, they are within the realm of science.
But how would these imperfections show up in science? To answer this, we must go to the sciences closest to the limits of what we can know about our world. The sciences closest to the basic building blocks of nature are quantum physics and cosmology. If there are matrix imperfections to be found, they are here.
We may find events beyond are ability to explain - but such events do not mean that the rules for the universe are themselves wrong, inconsistent, or contradictory. After all, the Pythagorean theorem is true, but a chimp could never understand it. Such knowledge is beyond a chimp's mental abilities. - but perhaps not forever. The real rules of universe can produce events always beyond our ability to comprehend even though we are much smarter than chimps. The kind of event we are looking for is not just unusual and hard to understand. Let's call that kind of problem a mere lack of understanding on our part. What we seek is an obvious contradiction or deep inconsistency within physics. Let's call these contradictions a real, but subtle, problem with the universe itself.
We have already found such inconsistencies: quantum physics is incompatible with general relativity. Both theories have been tested and seem consistent and correct on their own. All attempts over several decades to unite these failed. Although they describe very different realms (the very small vs the very large), they provide very different explanations for a basic force: gravity. And not just different, but contradictory. Other contradictions exist within quantum physics - such as the decay of neutral pions violates parity conservation. More problems, such as the 2-slit experiment and the Aspect experiment are hints that the universe is not what it seems.
As humanity looks back into the abyss of time, we learn more about the first moments of the universe. As we do so, we can test ever more rigorously theories about inflation and the overall nature of the cosmos. Will newer observations rule out various models of the universe and constrain others to the point than any remaining models contain contradictions with other models of physics? Will our understanding of the early cosmos show even deeper problems in quantum physics or general relativity? As Sherlock Holmes posited, "Once the obvious has been eliminated, whatever remains, no matter how improbable, must be the truth."
In mathematics, the presence of a single contradiction shows that the first premises are inconsistent. If the first premises are he very axioms used to create that mathematical system, then one contradiction shows they are incompatible with each othe
Rene Hollan, that is funny. Reminds me of this joke:
An engineer and a scientist have this long-standing debate over whether something can be done. Eventually, the engineer shows how to implement it and proves beyond a doubt that it works. The scientist then says, "Okay, so that works in practice, but does it work in theory?"
Take another look at the picture. It clearly shows the equator going through South America. The mouth of the Amazon River is right at the equator, and you can tell from the shape of SA where that is.
Kinda like those pre-law majors last decade.
on
Computing's Lost Allure
·
· Score: 2, Interesting
Students go into CS major thinking they can make a million bucks before they turn 30? Sounds like those students who studied law so they could sue somebody for a million bucks before they turned 30.
Glad to see the economic downturn has weeded out the wannabes who have no clue about designing or writing quality software.
There are still some highly trained engineers who know the hardware and software inside and out. But, they are surely outnumbered by the wannabes that only know some HTML tags and how to throw together a VB dialog by clicking on components. Sadly, I think they will be outnumbered for a long time, because there are too many VB "programmers" for the skilled and experienced software engineers to mentor and bring up to speed.
I know this great story about some engineers who wrote nuclear bomb simulations for supercomputer clusters at Lawrence-Livermore National Lab. After 12 CPU-months of processing time on a massively parallel cluster, they discovered the data was slightly off from predictions made by mathematical models. You can't just run the software through a debugger and wait 12 CPU-months for the bug to show up. Instead, they made test cases for small chunks of their code which they ran through a simulation of the bug in simulator software. Once they found the bug, they patched it on each part of the cluster while the process was *still* running.
These engineers are selected and trained to be that skilled, because if they did their jobs wrong, millions of people could *live*. (Silliness aside, they do save the US millions of $ because it would cost a lot to determine if our aging nuclear weapons are usable, and if any component within them needs to be replaced.) Personally, I would not that much responsibility. If I ever had to write a nuclear bomb simulator, I would probably make some real subtle bug that would not show up until after a year of computation.
Each step of this debugging effort took more skill than VB developers have.
Too many VB "programmers" out there think "I click, therefore I program." (I wish I could take credit for that quote, but I found it on the C/C++ Users Journal website in an editorial comment.) I have seen too many VB programmers who were basically clueless about abstraction, encapsulation, memory-managment, Big-O efficiency, or anything else except making GUI's quickly. This is not meant as flame-bait, because I have seen a small number of VB "programmers" actually become skilled software engineers.
The C/C++ Users Journal has an excellent editorial article about the low qulity of software. The premise is that a lot more people became software professionals than could be properly mentored into high quality developers. Also, a lot of people went into the profession who were simply not skilled at all. I think the article is right on the money when they say a main reason for low quality is that a lot of code has been written by people who just know VB or HTML and suddenly think they're hot-shot software architects.
If this mathematical marriage model is anything like Asimov's psychohistory, then perhaps this model is not about 2-person marriages, but of billion-person marriages.
Debugging quantum programs is going to be a real pain. This will allow a whole new type of bug. Before, people blamed bugs on faulty software, non-compliant compilers, and bad hardware. Soon they can blame their bugs on physics itself.
heisenbug:/hi:'zen-buhg/ n. [from Heisenberg's Uncertainty Principle in quantum physics] A bug that disappears or alters its behavior when one attempts to probe or isolate it. (This usage is not even particularly fanciful; the use of a debugger sometimes alters a program's operating environment significantly enough that buggy code, such as that which relies on the values of uninitialized memory, behaves quite differently.) Antonym of Bohr bug; see also mandelbug, schroedinbug. In C, nine out of ten heisenbugs result from uninitialized auto variables, fandango on core phenomena (esp. lossage related to corruption of the malloc arena) or errors that smash the stack.
The terms "software engineer" and "code-monkey" are about as far apart as you can get on a spectrum of prestigous titles. I just can't imagine anybody wanting to put "code-monkey" on their resume or anbody bragging about passing the MCCM exam (Microsoft Certified Code Monkey):-).
IMHO, requiring software developers to pass an engineering exam would be a good thing. There are too many "code-monkeys" who have no understanding of basic principles of software design and development. (Hmm... come to think of it, I know a few people with a "software architect" title who don't understand basic principles either.) A rigorous exam would weed out the "code-monkeys" in the field who are churning out bug-ridden messes for the engineers to clean up.
Let's count the advantages: 1. The average skill level among software professionals would go up. 2. The tolerance for and prevalance of buggy code will go down. 3. Also, if you are an accredited engineer, do you think some PHB is going to fire you just so he can hire low-paid labor in a third world country? 4. Software engineers would be able to command more respect among non-technical people. 5. Certified software engineers should command a higher salary just by passing the exam.
Now, having said all that, I don't like the current exams that software developers are encouraged to take. Exams created by corporations like the MCSE tend to be too vendor-specific to be useful for most software professionals. I once looked into the ICCP exam and learned that the concepts required for it were too old-fashioned or primitive for contemporary software design. So, I decided: why bother taking that exam?
If there ever is an exam for software professionals, I hope it is rigorous instead of being watered-down like the ICCP exams.
A pulsar does not produce pulses. The "pulse" that we see comes from a steady uniform beam of radiation from a rotating neutron star.
Ever see a lighthouse in action at night? That light is a steady beam from a very strong lamp mounted on a rotating platform. The platform spins at a steady rate. If you are nearby, such as on the ground looking up at the lighthouse, you can see the rotating beam. If you are on a ship, far away at sea, you don't see a rotating beam. Instead the observer on the ship sees a pulse.
The neutron star inside the Crab Nebula spins at a very steady rate of 33 rotations per seconds. It has 2 hot spots, one at the magnetic north pole, and another at the magnetic south pole. These hot spots produce a steady beam of light, which we see as 33 pulses per second.
Now, there are shockwaves produced by by seismic shifts within the neutron star. The neutron star has a crust that breaks into pieces and shifts around occasionally. (Think of earthquakes here, but the crust is very thin, and very dense, so the energy released is much greater than what powers an earthquake around here.) These shifts cause "hiccups" in the radiation beam. We can actually measure these hiccups because the "pulse" goes out of phase for a moment.
But, to finally answer your question, those shockwaves do not cause the "pulses", but merely adjust their timing for a brief moment. Also, a shockwave would be only an occasional event, rather than something that happens 33 times every second like clockwork.
The subpulses within the pulses are also very well timed, to within 2 nanoseconds. Since light travels about 61 cm in 2 nanoseconds, the hot spots that cause the subpulses are at most 61 cm wide.
We still have a few unknowns here, such as what confines the hot spot to such a small region. But, what causes the pulse itself is known.
Slashdot Mirror
Good plots are not Michael Bay's strong points. Neither is understanding reality.
Who else is bad enough to turn a dramatic historic event like the Attack on Pearl Harbor into a less than mediocre movie?
Here are some ways to make millions and not pay taxes.
Many companies pay their CEO's a $1 nominal salary. The company then takes out a $10M life insurance policy on the CEO. The CEO "borrows" money from the life insurance with a promise to pay it back later. The company forgives any money borrowed against the policy.
A company gives may perks to the CEO in lieu of a salary. (e.g. - free vacation with use of company jet, free use of mansion owned by company, free use of car owned by company, etc...) CEO effectively lives a lavish lifestyle without having to pay for it himself. The company pays the CEO in stocks and options that vest later so CEO can delay taxes on those while living quite comfortably.
The company is incorporated in a foreign nation, and pays the CEO a big salary in that nation's currency. CEO keeps salary in offshore bank account.
Do you want fries with that?
Anyhow, I think that the *actual* costs of overseas labor are going to start getting serious press soon as well, so hopefully that'll discourage the flava-of-the-month pointy hairs from shipping our work overseas, but I want a backup plan in case....
Outsource companies in India talk about how they cost only 20% of what US-based companies pay for software development. But, actual costs are closer to 80%. If anybody in your company starts talking about outsourcing, give them some hints from somebody who has been to India, and seen what it is like: Think Twice, and Don't Do It!
It takes a while to bring the Indian developers up to speed on the problem domain. It is one thing to know how to make software, but another to know how to make software to solve specific problems. It can take a year or more to transfer that knowledge for complex projects. So, during that time, US-Corp is paying for both its own developers, and the over seas developers. And they have to pay to bring those people over here or over there for training.
Many outsource companies have been known to get contracts to write software, and then go out and hire a dozen people. (Of course, they said up front to potential customers that they had the skills and resources.) I have met many really smart software designers and coders from India, but I have also met many whose only experience is that they read a book called: "Teach Yourself VB in 21 Days!" When you hire somebody for your own company, you can ask tough interview questions to determine the person's skill level. But, when you outsource to anywhere, even in the US, you might not get a chance to learn the skill level of whoever touches the source code. Sure, the company might let you talk to their smartest guys, but you won't know who is writing your source code the next day.
Will you ever get a chance to bring the code home? Maybe. Maybe not. Check your contract with the outsource company before you sign it. Even if they do share the source code with you, they may not want you to touch it yourself. Doing that can invalidate the contract and you have to pay their fees for breaking the contract. And too many PHB's think there is no need to bring the code home, if it can all be done over there. Try talking to a PHB who says: "All we need is the product, not any source code."
In many parts of India, basic utility infrastructure is just not up to American standards. This includes somewhat modern cities like Bangalore and Hyderabad where a lot of software is made. When I was in India, the power just simply went out occasionally. Sections of the city lost power for a few minutes or few hours. People got used to it.
One US corporate executive (won't say who) went over there to interview several companies for offshore software development. The lights went out 4 times during the first hour of the interview. The hosts politely explained that they have battery backups and use laptops with spare batteries. Needless to say, the exec was just not impressed. There was no deal.
I was riding in a taxi (one of those cute little "Amby" cars) and got stopped in one of those traffic jams that occur every few minutes. (Nobody obeys traffic rules consistently there, so traffic jams are just part of the overall experience.) People got used to it. Well, while waiting, I asked the driver about this unfinished bridge that partly crossed the highway. It looked like a highway entrance ramp where the lower part was about 10 feet up, then went for 50 feet, and the upper end just ended in an abrupt dropoff. No road connected to it, although if you extended it, the lower end would intersect the street eventually. It had been there a few years, with graffiti and chipped concrete. Was definately not new construction that had temporarily stopped.
The taxi driver said the city wanted to relieve traffic jams, and decided to make connection from this street over to another street a couple of kilometers away. The connection would be raised t
Yes, you can use simple templates with procedural programming. In that sense, knowledge of OOP is not needed to use templates. But, there are ways in which templates make OOP easier.
Templates can be combined nicely with several design patterns, such as observer, visitor, factory, and iterator. Template base classes for each of these design patterns can provide the common behaviors and implementations of these design patterns.
In addition to augmenting traditional OOP, templated classes can still have a lot of OOP-like properties. The classic examples here are in the STL. If we list the basic features of OOP, our list would include: Abstraction, Polymorphism, Inheritance, and Encapsulation.
The STL classes provide abstract interfaces into containers, algorithms, and iterators. The functors do provide a type of polymorphism through both templates. Several containers provide polymorphism through operator overloading. You can write classes to inherit from C++ containers and iterators, but that has various problems and issues with it. And they encapsulate the implementation details quite well. (e.g. - You don't have to worry about the mechanics of balancing red-black trees when you use std::map and std::set.)
You also need a destructor that walks the vector and calls delete() on each pointer-to-void.
Calling delete or delete[] on a void pointer is not safe. A void pointer is opaque, and so how would the compiler know which delete function to call? Each class can have its own delete and delete [] operators. You can get around this problem by casting the void pointer to the original type before deleting it.
If you don't have delete and delete [] operators for your classes, but always use the global delete and delete [] operators, then this is less of a problem. But, you still have the problem of calling the correct destructor - which is not available through a void pointer.
The STL Standard requires that each container destruct its elements when the container is destroyed, or the element is removed. If the container elements are objects, they are safely destructed. If they are primitives or pointers, then they have no destructors anyway.
If you need a container of pointers, then how about having a container of smart pointers instead? The smart pointers are objects and get destructed automatically. When it gets destructed, it can delete the object it points to, decrement a ref-count, or do whatever else it supposed to. A nice side effect is that you no longer need the unsafe cast to a void pointer.
From the parent post:
It will probably become more difficult for Joe Coder to just submit a patch to fix a bug. At worst, a lengthy background check will become required to verify that he hasn't worked on something similar for a corporation. At best, he'll have to complete some paperwork before he gains committer status.
That will only address future contributions. What about past contributions?
From the article:
This raises interesting succession questions. If a Linux contributor were hit by a bus tomorrow, his or her copyright would be part of their estate and could potentially be inherited by antagonistic outsiders more interested in the fast buck than in community-based software. Similar succession issues surround Torvalds' ownership of the Linux trademark.
Have any contributions been copyrighted? And if there are any copyrighted parts of Linux, it should be easy to excise and replace that section of code.
The outcome is obvious:
After SCO loses the lawsuit, they will owe IBM and RedHat millions. (And that says nothing about all the possible lawsuits they are begging for.) They are going into bankruptcy with a vengeance.
And after their stock price peaks, the investors will sell off and leave them to die.
It has already been mentioned in an earlier post that one possible outcome is that contributors to Linux will have to acknowledge their work as original. I would hate to see that happen, but it may be necessary to protect Linux distrubutors from lawsuits.
Has anybody gone through existing Linux source code and found anything proprietary? This is a tedious task, and very much after the fact. But, it could protect against future lawsuits.
Tigertigr, burning bright
in the forests of the night,
what mortal hand or eye
can frame thy fearful symmetry?
Tigertigr, I agree with you that a simulated world is always inferior to the real thing. This brings the question of whether inhabitants of the matrix should be able to discover imperfections. The matrix creators can't model the real world in all details correctly all the time. Perhaps an astute observer within the matrix can catch the matrix AI in the act of omission, and find a contradiction that shows the matrix world is too imperfect to be real.
The movie hinted at some imperfections, ESP, angels, and ghosts, but people inside the matrix interpreted experiences with ESP, angels, and ghosts within their own belief systems. Lots of New-Agers unthinkingly accept ESP, and many participants in traditional religions accept angels. These kinds of imperfections do not cause people to doubt their own reality. So, let's talk about a deeper imperfection, beyond the realm of what is easily observed by humans in everyday life.
Can any matrix imperfection be objectively and repeatedly observed - or even produced at will? As objective phenomenon, they are less likely to be unthinkingly incorporated into a religion or any other aggregate belief system. Instead, as measurable and testable phenomenon, they are within the realm of science.
But how would these imperfections show up in science? To answer this, we must go to the sciences closest to the limits of what we can know about our world. The sciences closest to the basic building blocks of nature are quantum physics and cosmology. If there are matrix imperfections to be found, they are here.
We may find events beyond are ability to explain - but such events do not mean that the rules for the universe are themselves wrong, inconsistent, or contradictory. After all, the Pythagorean theorem is true, but a chimp could never understand it. Such knowledge is beyond a chimp's mental abilities. - but perhaps not forever. The real rules of universe can produce events always beyond our ability to comprehend even though we are much smarter than chimps. The kind of event we are looking for is not just unusual and hard to understand. Let's call that kind of problem a mere lack of understanding on our part. What we seek is an obvious contradiction or deep inconsistency within physics. Let's call these contradictions a real, but subtle, problem with the universe itself.
We have already found such inconsistencies: quantum physics is incompatible with general relativity. Both theories have been tested and seem consistent and correct on their own. All attempts over several decades to unite these failed. Although they describe very different realms (the very small vs the very large), they provide very different explanations for a basic force: gravity. And not just different, but contradictory. Other contradictions exist within quantum physics - such as the decay of neutral pions violates parity conservation. More problems, such as the 2-slit experiment and the Aspect experiment are hints that the universe is not what it seems.
As humanity looks back into the abyss of time, we learn more about the first moments of the universe. As we do so, we can test ever more rigorously theories about inflation and the overall nature of the cosmos. Will newer observations rule out various models of the universe and constrain others to the point than any remaining models contain contradictions with other models of physics? Will our understanding of the early cosmos show even deeper problems in quantum physics or general relativity? As Sherlock Holmes posited, "Once the obvious has been eliminated, whatever remains, no matter how improbable, must be the truth."
In mathematics, the presence of a single contradiction shows that the first premises are inconsistent. If the first premises are he very axioms used to create that mathematical system, then one contradiction shows they are incompatible with each othe
Rene Hollan, that is funny. Reminds me of this joke:
An engineer and a scientist have this long-standing debate over whether something can be done. Eventually, the engineer shows how to implement it and proves beyond a doubt that it works. The scientist then says, "Okay, so that works in practice, but does it work in theory?"
Take another look at the picture. It clearly shows the equator going through South America. The mouth of the Amazon River is right at the equator, and you can tell from the shape of SA where that is.
Students go into CS major thinking they can make a million bucks before they turn 30? Sounds like those students who studied law so they could sue somebody for a million bucks before they turned 30.
Glad to see the economic downturn has weeded out the wannabes who have no clue about designing or writing quality software.
There are still some highly trained engineers who know the hardware and software inside and out. But, they are surely outnumbered by the wannabes that only know some HTML tags and how to throw together a VB dialog by clicking on components. Sadly, I think they will be outnumbered for a long time, because there are too many VB "programmers" for the skilled and experienced software engineers to mentor and bring up to speed.
I know this great story about some engineers who wrote nuclear bomb simulations for supercomputer clusters at Lawrence-Livermore National Lab. After 12 CPU-months of processing time on a massively parallel cluster, they discovered the data was slightly off from predictions made by mathematical models. You can't just run the software through a debugger and wait 12 CPU-months for the bug to show up. Instead, they made test cases for small chunks of their code which they ran through a simulation of the bug in simulator software. Once they found the bug, they patched it on each part of the cluster while the process was *still* running.
These engineers are selected and trained to be that skilled, because if they did their jobs wrong, millions of people could *live*. (Silliness aside, they do save the US millions of $ because it would cost a lot to determine if our aging nuclear weapons are usable, and if any component within them needs to be replaced.) Personally, I would not that much responsibility. If I ever had to write a nuclear bomb simulator, I would probably make some real subtle bug that would not show up until after a year of computation.
Each step of this debugging effort took more skill than VB developers have.
Too many VB "programmers" out there think "I click, therefore I program." (I wish I could take credit for that quote, but I found it on the C/C++ Users Journal website in an editorial comment.) I have seen too many VB programmers who were basically clueless about abstraction, encapsulation, memory-managment, Big-O efficiency, or anything else except making GUI's quickly. This is not meant as flame-bait, because I have seen a small number of VB "programmers" actually become skilled software engineers.
C++ allows you to bind one identifier to another using references.
int a = 1;
int & b = a;
Whatevers happens to a also happens to b.
If Iraqis start downloading their own music, will Ms. Rosen send inspectors to look for all the Iraqi computers?
The C/C++ Users Journal has an excellent editorial article about the low qulity of software. The premise is that a lot more people became software professionals than could be properly mentored into high quality developers. Also, a lot of people went into the profession who were simply not skilled at all. I think the article is right on the money when they say a main reason for low quality is that a lot of code has been written by people who just know VB or HTML and suddenly think they're hot-shot software architects.
If this mathematical marriage model is anything like Asimov's psychohistory, then perhaps this model is not about 2-person marriages, but of billion-person marriages.
After this is over, I would bet dollars against dimes the RIAA still won't pay musicians anything more than a living wage.
I saw him do a presentation in Portland few months back, and it was pretty mind-blowing.
So, was he in two places at once? And, when you saw him, was he alive or dead?
Debugging quantum programs is going to be a real pain. This will allow a whole new type of bug. Before, people blamed bugs on faulty software, non-compliant compilers, and bad hardware. Soon they can blame their bugs on physics itself.
heisenbug: /hi:'zen-buhg/ n. [from Heisenberg's Uncertainty Principle in quantum physics] A bug that disappears or alters its behavior when one attempts to probe or isolate it. (This usage is not even particularly fanciful; the use of a debugger sometimes alters a program's operating environment significantly enough that buggy code, such as that which relies on the values of uninitialized memory, behaves quite differently.) Antonym of Bohr bug; see also mandelbug, schroedinbug. In C, nine out of ten heisenbugs result from uninitialized auto variables, fandango on core phenomena (esp. lossage related to corruption of the malloc arena) or errors that smash the stack.
The terms "software engineer" and "code-monkey" are about as far apart as you can get on a spectrum of prestigous titles. I just can't imagine anybody wanting to put "code-monkey" on their resume or anbody bragging about passing the MCCM exam (Microsoft Certified Code Monkey) :-) .
IMHO, requiring software developers to pass an engineering exam would be a good thing. There are too many "code-monkeys" who have no understanding of basic principles of software design and development. (Hmm... come to think of it, I know a few people with a "software architect" title who don't understand basic principles either.) A rigorous exam would weed out the "code-monkeys" in the field who are churning out bug-ridden messes for the engineers to clean up.
Let's count the advantages:
1. The average skill level among software professionals would go up.
2. The tolerance for and prevalance of buggy code will go down.
3. Also, if you are an accredited engineer, do you think some PHB is going to fire you just so he can hire low-paid labor in a third world country?
4. Software engineers would be able to command more respect among non-technical people.
5. Certified software engineers should command a higher salary just by passing the exam.
Now, having said all that, I don't like the current exams that software developers are encouraged to take. Exams created by corporations like the MCSE tend to be too vendor-specific to be useful for most software professionals. I once looked into the ICCP exam and learned that the concepts required for it were too old-fashioned or primitive for contemporary software design. So, I decided: why bother taking that exam?
If there ever is an exam for software professionals, I hope it is rigorous instead of being watered-down like the ICCP exams.
Thinking of the Little Green Men hypothesis which was once proposed to explain why pulsars are so regular?
A pulsar does not produce pulses. The "pulse" that we see comes from a steady uniform beam of radiation from a rotating neutron star.
Ever see a lighthouse in action at night? That light is a steady beam from a very strong lamp mounted on a rotating platform. The platform spins at a steady rate. If you are nearby, such as on the ground looking up at the lighthouse, you can see the rotating beam. If you are on a ship, far away at sea, you don't see a rotating beam. Instead the observer on the ship sees a pulse.
The neutron star inside the Crab Nebula spins at a very steady rate of 33 rotations per seconds. It has 2 hot spots, one at the magnetic north pole, and another at the magnetic south pole. These hot spots produce a steady beam of light, which we see as 33 pulses per second.
Now, there are shockwaves produced by by seismic shifts within the neutron star. The neutron star has a crust that breaks into pieces and shifts around occasionally. (Think of earthquakes here, but the crust is very thin, and very dense, so the energy released is much greater than what powers an earthquake around here.) These shifts cause "hiccups" in the radiation beam. We can actually measure these hiccups because the "pulse" goes out of phase for a moment.
But, to finally answer your question, those shockwaves do not cause the "pulses", but merely adjust their timing for a brief moment. Also, a shockwave would be only an occasional event, rather than something that happens 33 times every second like clockwork.
The subpulses within the pulses are also very well timed, to within 2 nanoseconds. Since light travels about 61 cm in 2 nanoseconds, the hot spots that cause the subpulses are at most 61 cm wide.
We still have a few unknowns here, such as what confines the hot spot to such a small region. But, what causes the pulse itself is known.