That doesn't make any sense for things where training is needed though. 1% of laymen being better than civil engineers at building extremely large bridges? 1% of laymen being better at fixing cars than a mechanic? How about 1% of laymen being better at basketball than NBA players? It makes absolutely no sense, because we are talking about things where the training time is extremely valuable, and guessing at random will not help you, because there are too many possible answers.
Even in yes/no questions, if 1% beats the professionals, it's because the questions are so hard, that the results might as well be random.
The most you could say is that we are bad at putting the most talented people at a certain field in the right position to use their advantage. For instance, I doubt that the Americans that have the best potential to be soccer stars happen to pick soccer, if just because it's not a very popular sport here compared to most of the world. However, in something like Basketball, where it's very easy to identify talent, as being very tall is a major advantage, it's very likely that we are pretty close to the best there is in the population: For instance, 17% of people in the US that are 7 feet play, or have played, in the NBA!
The wisdom of crowds works doesn't have anything to do with having experts. After all, the experts have no way of influencing the crowd. It is a well defined phenomenon that works when people's biases are pretty random, so mistakes cancel each other out. It's a lower quality estimation mechanism than a market, where people that are sure of their answer can be 'louder' than those that don't know said answer, and it lacks the feedback mechanisms of a market, but still, it is helpful to predict things based on widely available information. Ask the crowd information few of them have any idea about, and their result will suck.
So what does the average beating CIA personnel? That the CIA's biases are large enough to need quite a bit of quality control.
Now, having a 1% of the respondents be far better than the CIA experts probably means nothing. If I invite 3000 people over to guess how 10 coin flips will turn out, chances are one or two of them will guess all of them correctly, but that would not make them seers capable of seeing the future. how many people were worse than 30% worse than those same CIA experts?
The opponent is forced to pick 50% rock, but he has no limitations other than that. If you went 100% paper, you'd not beat me playing 50% rock by more than a tiny sliver of a percent it takes me to realize you are going 50% paper.
And the problem has nothing to do with the someone not just picking rock, but doing so in a very predictable manner. Otherwise, we'd not be talking about someone picking rock 50% of the time, but playing against someone that plays randomly, but tells you what he is picking half the time, never lying. That's a very, very boring brainteaser.
The first naive approach that doesn't assume idiocy on the other side's part is to assume he'll try to guess our play. If we play in a non deterministic fashion, his best options is probably random, but instead of.33/.33/.33, we get.50/.25/.25. Against an opponent doing that, you could go.25/.50/.25, and win quite a bit.
If he is forced to get at least 50% rock after a certain number of plays, then we can change our probabilities depending on how far from the standard distribution our opponent is: For instance, if we were playing to 10 throws, and he never picked rock in the first 5, we'd get him in the last 5, because his moves are forced. To avoid this, someone that has to reach that 50% will probably also change their probabilities after every throw, just to avoid such a 'free' run. One might even consider starting with an over 50% rock probability, because under that set of rules, having overplayed rock lets us play more optimally later, while underplaying rock leads to major losses.
Either way, a more detailed problem specification is required.
This is more easily handled in Mercurial's queues system. You can keep a bunch of patches in a queue like that, and those patches will just be magically applied. It's pretty useful for a whole lot of situations.
The main practical difference, past the API, is their approach to branching: A git branch is a mercurial bookmark. There are no concept like mercurial's branch in git. There's also how git has this crazy staging area that is the cause of 90% of bad commits to our git repos. Commits that are missing a file, or have an extra file, are the bane of SVN and Git repos. In hg, the expected behavior is commit everything that is not in a patch. More discipline required, less chances of shooting yourself in the foot.
As far as the interface goes, other than the well known stuff, there's the fact that default behaviors seem to be all built around pulls, not pushes, so if your typical corporate environment, where pulls are often nonsense, people get very confused when 'natural' behaviors tell them that the files that changed from a merge are the files from the upstream, that they did not edit, and things like that. To minimize it, I keep telling people to avoid git pull like the plague, and instead use git fetch, followed by git rebase as the baseline case.
Either way, both are pretty useful, and beat SVN in almost all use cases. I just think that it's easier to teach people hg than telling people to learn a bunch about git internals before they can contribute properly.
It might motivate you, but not to actually be better: Many things that make you better will be tracked to the team, not to you, and a good team still has to have a poor performer. So stack ranking motivates people to make sure some people are behind you, and to make sure that your manager actually likes you, instead of making your product better. Creating conflict for the good of the application is not great idea in a stack ranking organization, because it'll make the manager work harder, and thus not endear it to him.
I remember the last time I was in a stack ranking org. Our team was way too good: A few developers were quite a bit better at their jobs than the manager even understood. Who was getting the good review? A guy that was pretty darned average, code-wise, but that played D&D with the manager. I at least managed to avoid being called the 'bad one', but it was pretty clear that there was very little future in that kind of organization unless you managed to surround yourself by relatively bad developers.
Decisions on running a company are often a whole lot like investing in stocks: You only know if a decision is good or not way after you make it, and the reason why the decision was sound probably had very little to do with the reasoning you had at the time. This makes it extremely easy for people to think they are geniuses, when in reality, all they are is very lucky. Having picked stocks well for a few years, or having led a corporation that became huge, does not mean that your future decisions in that realm will continue to be any good.
But it doesn't matter: Imagine an unbreakable crypto: If you enter the right password, you are in. If you do not have it, infinite computer resources won't help you. Well, that environment is still an extremely dangerous environment for non-reversible transactions that cannot be manipulated by an authority, because most attacks on computer security work regardless of how good a cypher you use.
If you are attacking anything large, you just attack the keys. With no central authority, there is no way to recover keys, or ask for keys to be changed. Therefore, key management itself will be weakened due to how catastrophic it is to lose the keys. The harder you make it to lose all your bitcoins, the easier you make it to attack your keys.
So putting all the trust in the platform's security is like saying that a house is safe because you installed the best door money can buy. But there's still windows, and walls, and a roof, and a basement... Make them all perfectly secure, and you can't get into the house itself.
Yep, it's called refuge. And that's why you will find, today, that the recommendation is to do exactly as you say. You'll even find Monsanto, BASF and Pioneer telling you to do that, and even selling the seeds for both. If you find a farmer that doesn't know that, he's not paying attention.
Now, good luck finding people that know this unless they have farmers or agronomists in the family.
JavaFX is still rather component poor, just like Swing was. It's ultimately Swing's biggest problem IMO: To do anything even mildly interesting, you have to build your own components, or do major extensions on the base ones. How much pain have people inflicted on themselves extending JTable? And no mention of the layout manager mess, only solved by third parties, back when Swing was already considered semi-dead: I'd trade every single layout option built into JavaFX for MigLayout.
Not really. We had Macho Man Randy Savage. He was both noble and a Savage. When Q'uq'umatz was going to destroy the world, at the end of the Mayan Calendar, Macho gave his life to wrestle the world away from the grip of the great creator snake. What can be nobler than that?
Well, it's just as illegal to download an episode than is 1 year old, than it is to download one that is 50 years old. If the punishment is the same, why wouldn't you download the latest stuff?
He'd be voicing the concern no matter what, because he believes he is better served by infinite copyright.
It's not an uncommon belief. If the code is well factored, and has a good narrative, comments can actually be harmful. This is because comments have a very major problem: They can be updated, and are often updated, at a different time the code does. So it's not rare to find comments that are downright deceitful: They don't say what the code does: But what the code used to do, years ago, before the system worked. So making the code agree with the comments will break the app.
We have the same problem with most specifications: They are instantly out of date.
So what do we do? We want something that helps us explain what the code does, and yet cannot deceive us on whether it's true or not. We call those executable specifications and unit tests. If the tests don't pass, they don't reflect reality, and we have to figure out which one is right. If the Executable specs stopped running, then we know what broke them.
So I'd leave comments down to situations where I am stuck doing a level of language trickery that I do not expect my average reader to understand, but that I cannot actually avoid. So maybe a comment on a performance optimization, or on some crazy type conversion trickery in Scala. But every time I feel like commenting is necessary, I know my code is doing something I am not happy about.
User Friendly feels extremely dated now, but that's not because it was a bad comic back then, but because it was trying to capture the geek mindset of the time. It's a bit like Dilbert, a comic that only really makes sense when you've spent enough time in a megacorp's big cubicle farm. The main difference is that User Friendly came from an upbeat world that, frankly, does not exist anymore, so today it just can't be funny.
It was more than just sensical: They were using it to locate a server that was vulnerable to a real exploit for a real exploit for a real(if old) version of SSH1:
It's always disappointing when terrible movies mix total nonsense with very real information, as it raises expectations too much. Other examples of somewhat correct lingo mixed with nonsense is the scene in Hackers where they go through real books that actual hackers from way back then would find useful. But even if I bring my old college book on compiler design to work, risk getting called into Human Resources by riding on a skateboard through the building, and telling everyone that we should start hacking the Gibson, it'd still not make any of my female coworkers actually look like Angelina Jolie.
Did you read the entire post? Do a software update, and you still need the blocks to be sent and received. And while all clients do not need the entire blockchain, while you still have a single one, you will have problems. In architectural terms, a blockchain behaves like a single, tightly synchronized queue. There are good reasons for doing that: It's not as if the people designing the system are incompetent. However, the design decisions that make sure that no coin is spent twice make scaling very inefficient. Any cryptocurrency that still retains the same properties as Bitcoin will be prohibitively expensive to run, in both power and bandwidth.
We have transaction systems that support the necessary loads: They are useful in many Big Data applications. But to achieve linear scaling, we make sacrifices that would be unacceptable for bitcoin. Even the best solutions out there, which would soften things to guaranteeing ordering for each specific wallet, would only produce moderate improvements over the blockchain: They still would not be able to handle the transaction numbers we'd need.
The problem is that it has to be something that doesn't make it easy for a hacker to transfer all my funds to himself, with no recourse from me. With crypto currencies, I have to trust my computer security well more than I currently trust the computer security's state of the art. And even if that works, I'd still need recourse to deal with merchant fraud.
Either way, cryptocurrencies do not really solve the problem.
How are we going to inform the other 90% of the dangers of HTML? I am sure they also don't understand how dangerous PHP can be, and don't want to vaccinate their daughters against it.
In the real world, when you get to anything even mildly complicated, you don't look at symbolic representations, and instead use numerical methods anyway. The geometric representation of those numerical methods is often pretty simple too.
Now, for something complicated, look at graphical representations of a matrix's dot product. We use it all the frigging time in computer graphics, but it's far harder to 'see' how it all works than it should.
Except monsanto is not only the other company making GMOs. It's not unlike avoiding all pharmacies because I hate Bayer. Or asking for especially labeling on everything because I hate BASF (who also do GMO work, BTW)
If the issue is informed consumers, what are we trying to inform them of, and why? If it is about safety, you don't have to treat GMOs as a 'flag', but go into the genetics of things. If it's really about knowing which companies are involved in producing something, so we can discriminate against them, then why do that just with food?
If your IDE is producing much scaffolding, the problem is not the IDE, but writing in a technology where said scaffolding could be seen as desirable to anyone. For instance, look at the state of Java circa 2002. You have EJB 2.0, full of boilerplate. Then there's Spring's ginormous xml configuration files, which you have to get exactly right, and in line with the code. Talking to a database? There's this tool called hibernate, which reads this finely crafted xml files, that have to exactly match both your classes on one hand, and your database on the other. In that environment, you'd be NUTS not to use and IDE, but you could argue that you'd also have to be nuts to subject people to such a development environment, full of finely crafted configuration for applications that, in 99 percent of cases, only change a few database connection strings in the configuration, while the rest is just code written in XML.
More modern version of the same technologies minimize the use of that silly boilerplate. Completely newer technologies just cut the boilerplate down to so much, IDE scaffolding doesn't even exist, because there is no boilerplate for the IDE to generate. Who thought having to explicitly create all getters and setters was a good idea anyway? Why create rituals where, to make a change, I need to change 3 files in unison, or the whole thing will break?
If I am writing library, and I am even tempted to write some little IDE extension for it, it means I did something wrong with my library design.
That idea of value was nice, in the 19th century. While one can come up with a concept of value, that value is not the same for all actors: Value is not really cost of production, but utility. And we also have to consider marginal value: Water is extremely valuable, but we have so much, the marginal value of producing another glass of drinking water is pretty low.
Many things will never be sold for how much they cost to make, because their actual value, their utility, is far lower than the cost of production. And since values and costs of production change over time, it's not difficult to find items for sale for less than the cost of production.
Then we have stocks and bubbles. The price of a stock doesn't just reflect how much it's worth now, but how much it's expected to be worth in the future. This does cover speculation too: There is a utility in holding something if you expect to be able to resell it for more tomorrow. So I'd not say that what people call bubbles has that much to do with being far from fundamentals, but with information being propagated that shows that the current estimate of future value is very different from the current price. If a pharma company is on trials to cure a major kind of cancer, its stock will go up. If the trials are unsuccessful, it might go all the way to zero. But that doesn't mean that there was a bubble. This is especially true with stocks, where, if you really think a price is way too high, a hedge fund can make money shorting it.
So, when calling something a bubble, we have to have some very strong reasons to do so. You could claim that the Efficient Market Hypothesis doesn't hold, even at the weakest of levels, at which point you are very, very far from mainstream economics. You can instead claim that the problem is that the market is being manipulated, and that might be the case with Bitcoin, for instance. Maybe a company is committing major fraud, and most people don't know about it, but you do have insider knowledge. That'd not be much of a bubble, just plain decepcion. You could also claim that there are major amounts of risk baked into the price, so you can expect volatility. Many would argue that the financial crisis, for instance, was really all about the Fed just not making any sense, and not reacting to a sudden increase to the demand of money.
So when it comes to bitcoin, how do you explain the bubble? My favorite is a combination of price manipulation from actors that control way too much bitcoin for a market to be all that efficient, tied to a high amount of variance in possible outcomes. If through something strange, Bitcoin actually happened to become important, then its current price is very low compared to what it should be. If it is not, then the current price is way too high. So what we see is a market that is mostly known by people who are just spending a few dollars hoping to make millions, so for them, it's a lottery ticket. Buying a lottery ticket, hand having it lose, doesn't mean that there was an asset bubble with the tickets, does it?:)
It''s not just facebook: There's plenty of large companies out there flush with cash that are not investing the money on their own base operation, but buying other people's.
It always seemed silly to me, given how bad a track record there is on acquisitions. More often than not, it's not just that the merger produces no value through synergy, but value is actually destroyed, as the bought company quickly loss independence, then talent. All you get is a brand.
In the only places where I've seen good successes is when purchasing very small organizations, where all you are really doing is paying a few people very large amounts of money to come work for you, instead of being independent. But then, why not just bite the bullet and do whatever it takes to make the right kind of candidate to come work for you?
Don't forget the major advantage in natural resources. America has historically been seen as an industrial powerhouse, but the US's can crush anyone in agriculture and resource extraction. And all that, with very low population density, so the resources per capita are insane.
Slashdot Mirror
That doesn't make any sense for things where training is needed though. 1% of laymen being better than civil engineers at building extremely large bridges? 1% of laymen being better at fixing cars than a mechanic? How about 1% of laymen being better at basketball than NBA players? It makes absolutely no sense, because we are talking about things where the training time is extremely valuable, and guessing at random will not help you, because there are too many possible answers.
Even in yes/no questions, if 1% beats the professionals, it's because the questions are so hard, that the results might as well be random.
The most you could say is that we are bad at putting the most talented people at a certain field in the right position to use their advantage. For instance, I doubt that the Americans that have the best potential to be soccer stars happen to pick soccer, if just because it's not a very popular sport here compared to most of the world. However, in something like Basketball, where it's very easy to identify talent, as being very tall is a major advantage, it's very likely that we are pretty close to the best there is in the population: For instance, 17% of people in the US that are 7 feet play, or have played, in the NBA!
So yeah, that bell curve... go read again.
Except this isn't how it works at all.
The wisdom of crowds works doesn't have anything to do with having experts. After all, the experts have no way of influencing the crowd. It is a well defined phenomenon that works when people's biases are pretty random, so mistakes cancel each other out. It's a lower quality estimation mechanism than a market, where people that are sure of their answer can be 'louder' than those that don't know said answer, and it lacks the feedback mechanisms of a market, but still, it is helpful to predict things based on widely available information. Ask the crowd information few of them have any idea about, and their result will suck.
So what does the average beating CIA personnel? That the CIA's biases are large enough to need quite a bit of quality control.
Now, having a 1% of the respondents be far better than the CIA experts probably means nothing. If I invite 3000 people over to guess how 10 coin flips will turn out, chances are one or two of them will guess all of them correctly, but that would not make them seers capable of seeing the future. how many people were worse than 30% worse than those same CIA experts?
The opponent is forced to pick 50% rock, but he has no limitations other than that. If you went 100% paper, you'd not beat me playing 50% rock by more than a tiny sliver of a percent it takes me to realize you are going 50% paper.
And the problem has nothing to do with the someone not just picking rock, but doing so in a very predictable manner. Otherwise, we'd not be talking about someone picking rock 50% of the time, but playing against someone that plays randomly, but tells you what he is picking half the time, never lying. That's a very, very boring brainteaser.
The first naive approach that doesn't assume idiocy on the other side's part is to assume he'll try to guess our play. If we play in a non deterministic fashion, his best options is probably random, but instead of .33/.33/.33, we get .50/.25/.25. Against an opponent doing that, you could go .25/.50/.25, and win quite a bit.
If he is forced to get at least 50% rock after a certain number of plays, then we can change our probabilities depending on how far from the standard distribution our opponent is: For instance, if we were playing to 10 throws, and he never picked rock in the first 5, we'd get him in the last 5, because his moves are forced. To avoid this, someone that has to reach that 50% will probably also change their probabilities after every throw, just to avoid such a 'free' run. One might even consider starting with an over 50% rock probability, because under that set of rules, having overplayed rock lets us play more optimally later, while underplaying rock leads to major losses.
Either way, a more detailed problem specification is required.
This is more easily handled in Mercurial's queues system. You can keep a bunch of patches in a queue like that, and those patches will just be magically applied. It's pretty useful for a whole lot of situations.
The main practical difference, past the API, is their approach to branching: A git branch is a mercurial bookmark. There are no concept like mercurial's branch in git. There's also how git has this crazy staging area that is the cause of 90% of bad commits to our git repos. Commits that are missing a file, or have an extra file, are the bane of SVN and Git repos. In hg, the expected behavior is commit everything that is not in a patch. More discipline required, less chances of shooting yourself in the foot.
As far as the interface goes, other than the well known stuff, there's the fact that default behaviors seem to be all built around pulls, not pushes, so if your typical corporate environment, where pulls are often nonsense, people get very confused when 'natural' behaviors tell them that the files that changed from a merge are the files from the upstream, that they did not edit, and things like that. To minimize it, I keep telling people to avoid git pull like the plague, and instead use git fetch, followed by git rebase as the baseline case.
Either way, both are pretty useful, and beat SVN in almost all use cases. I just think that it's easier to teach people hg than telling people to learn a bunch about git internals before they can contribute properly.
It might motivate you, but not to actually be better: Many things that make you better will be tracked to the team, not to you, and a good team still has to have a poor performer. So stack ranking motivates people to make sure some people are behind you, and to make sure that your manager actually likes you, instead of making your product better. Creating conflict for the good of the application is not great idea in a stack ranking organization, because it'll make the manager work harder, and thus not endear it to him.
I remember the last time I was in a stack ranking org. Our team was way too good: A few developers were quite a bit better at their jobs than the manager even understood. Who was getting the good review? A guy that was pretty darned average, code-wise, but that played D&D with the manager. I at least managed to avoid being called the 'bad one', but it was pretty clear that there was very little future in that kind of organization unless you managed to surround yourself by relatively bad developers.
Decisions on running a company are often a whole lot like investing in stocks: You only know if a decision is good or not way after you make it, and the reason why the decision was sound probably had very little to do with the reasoning you had at the time. This makes it extremely easy for people to think they are geniuses, when in reality, all they are is very lucky. Having picked stocks well for a few years, or having led a corporation that became huge, does not mean that your future decisions in that realm will continue to be any good.
But it doesn't matter: Imagine an unbreakable crypto: If you enter the right password, you are in. If you do not have it, infinite computer resources won't help you. Well, that environment is still an extremely dangerous environment for non-reversible transactions that cannot be manipulated by an authority, because most attacks on computer security work regardless of how good a cypher you use.
If you are attacking anything large, you just attack the keys. With no central authority, there is no way to recover keys, or ask for keys to be changed. Therefore, key management itself will be weakened due to how catastrophic it is to lose the keys. The harder you make it to lose all your bitcoins, the easier you make it to attack your keys.
So putting all the trust in the platform's security is like saying that a house is safe because you installed the best door money can buy. But there's still windows, and walls, and a roof, and a basement... Make them all perfectly secure, and you can't get into the house itself.
Yep, it's called refuge. And that's why you will find, today, that the recommendation is to do exactly as you say. You'll even find Monsanto, BASF and Pioneer telling you to do that, and even selling the seeds for both. If you find a farmer that doesn't know that, he's not paying attention.
Now, good luck finding people that know this unless they have farmers or agronomists in the family.
JavaFX is still rather component poor, just like Swing was. It's ultimately Swing's biggest problem IMO: To do anything even mildly interesting, you have to build your own components, or do major extensions on the base ones. How much pain have people inflicted on themselves extending JTable? And no mention of the layout manager mess, only solved by third parties, back when Swing was already considered semi-dead: I'd trade every single layout option built into JavaFX for MigLayout.
Not really. We had Macho Man Randy Savage. He was both noble and a Savage. When Q'uq'umatz was going to destroy the world, at the end of the Mayan Calendar, Macho gave his life to wrestle the world away from the grip of the great creator snake. What can be nobler than that?
Well, it's just as illegal to download an episode than is 1 year old, than it is to download one that is 50 years old. If the punishment is the same, why wouldn't you download the latest stuff?
He'd be voicing the concern no matter what, because he believes he is better served by infinite copyright.
It's not an uncommon belief. If the code is well factored, and has a good narrative, comments can actually be harmful. This is because comments have a very major problem: They can be updated, and are often updated, at a different time the code does. So it's not rare to find comments that are downright deceitful: They don't say what the code does: But what the code used to do, years ago, before the system worked. So making the code agree with the comments will break the app.
We have the same problem with most specifications: They are instantly out of date.
So what do we do? We want something that helps us explain what the code does, and yet cannot deceive us on whether it's true or not. We call those executable specifications and unit tests. If the tests don't pass, they don't reflect reality, and we have to figure out which one is right. If the Executable specs stopped running, then we know what broke them.
So I'd leave comments down to situations where I am stuck doing a level of language trickery that I do not expect my average reader to understand, but that I cannot actually avoid. So maybe a comment on a performance optimization, or on some crazy type conversion trickery in Scala. But every time I feel like commenting is necessary, I know my code is doing something I am not happy about.
User Friendly feels extremely dated now, but that's not because it was a bad comic back then, but because it was trying to capture the geek mindset of the time. It's a bit like Dilbert, a comic that only really makes sense when you've spent enough time in a megacorp's big cubicle farm. The main difference is that User Friendly came from an upbeat world that, frankly, does not exist anymore, so today it just can't be funny.
It was more than just sensical: They were using it to locate a server that was vulnerable to a real exploit for a real exploit for a real(if old) version of SSH1:
http://nmap.org/movies/
It's always disappointing when terrible movies mix total nonsense with very real information, as it raises expectations too much. Other examples of somewhat correct lingo mixed with nonsense is the scene in Hackers where they go through real books that actual hackers from way back then would find useful. But even if I bring my old college book on compiler design to work, risk getting called into Human Resources by riding on a skateboard through the building, and telling everyone that we should start hacking the Gibson, it'd still not make any of my female coworkers actually look like Angelina Jolie.
All those movies, full of lies.
Did you read the entire post? Do a software update, and you still need the blocks to be sent and received. And while all clients do not need the entire blockchain, while you still have a single one, you will have problems. In architectural terms, a blockchain behaves like a single, tightly synchronized queue. There are good reasons for doing that: It's not as if the people designing the system are incompetent. However, the design decisions that make sure that no coin is spent twice make scaling very inefficient. Any cryptocurrency that still retains the same properties as Bitcoin will be prohibitively expensive to run, in both power and bandwidth.
We have transaction systems that support the necessary loads: They are useful in many Big Data applications. But to achieve linear scaling, we make sacrifices that would be unacceptable for bitcoin. Even the best solutions out there, which would soften things to guaranteeing ordering for each specific wallet, would only produce moderate improvements over the blockchain: They still would not be able to handle the transaction numbers we'd need.
The problem is that it has to be something that doesn't make it easy for a hacker to transfer all my funds to himself, with no recourse from me. With crypto currencies, I have to trust my computer security well more than I currently trust the computer security's state of the art. And even if that works, I'd still need recourse to deal with merchant fraud.
Either way, cryptocurrencies do not really solve the problem.
How are we going to inform the other 90% of the dangers of HTML? I am sure they also don't understand how dangerous PHP can be, and don't want to vaccinate their daughters against it.
In the real world, when you get to anything even mildly complicated, you don't look at symbolic representations, and instead use numerical methods anyway. The geometric representation of those numerical methods is often pretty simple too.
Now, for something complicated, look at graphical representations of a matrix's dot product. We use it all the frigging time in computer graphics, but it's far harder to 'see' how it all works than it should.
Except monsanto is not only the other company making GMOs. It's not unlike avoiding all pharmacies because I hate Bayer. Or asking for especially labeling on everything because I hate BASF (who also do GMO work, BTW)
If the issue is informed consumers, what are we trying to inform them of, and why? If it is about safety, you don't have to treat GMOs as a 'flag', but go into the genetics of things. If it's really about knowing which companies are involved in producing something, so we can discriminate against them, then why do that just with food?
We could solve that problem, and have major savings by replacing medicare with a 'free meth and oxycodone' program.
If your IDE is producing much scaffolding, the problem is not the IDE, but writing in a technology where said scaffolding could be seen as desirable to anyone. For instance, look at the state of Java circa 2002. You have EJB 2.0, full of boilerplate. Then there's Spring's ginormous xml configuration files, which you have to get exactly right, and in line with the code. Talking to a database? There's this tool called hibernate, which reads this finely crafted xml files, that have to exactly match both your classes on one hand, and your database on the other. In that environment, you'd be NUTS not to use and IDE, but you could argue that you'd also have to be nuts to subject people to such a development environment, full of finely crafted configuration for applications that, in 99 percent of cases, only change a few database connection strings in the configuration, while the rest is just code written in XML.
More modern version of the same technologies minimize the use of that silly boilerplate. Completely newer technologies just cut the boilerplate down to so much, IDE scaffolding doesn't even exist, because there is no boilerplate for the IDE to generate. Who thought having to explicitly create all getters and setters was a good idea anyway? Why create rituals where, to make a change, I need to change 3 files in unison, or the whole thing will break?
If I am writing library, and I am even tempted to write some little IDE extension for it, it means I did something wrong with my library design.
That idea of value was nice, in the 19th century. While one can come up with a concept of value, that value is not the same for all actors: Value is not really cost of production, but utility. And we also have to consider marginal value: Water is extremely valuable, but we have so much, the marginal value of producing another glass of drinking water is pretty low.
Many things will never be sold for how much they cost to make, because their actual value, their utility, is far lower than the cost of production. And since values and costs of production change over time, it's not difficult to find items for sale for less than the cost of production.
Then we have stocks and bubbles. The price of a stock doesn't just reflect how much it's worth now, but how much it's expected to be worth in the future. This does cover speculation too: There is a utility in holding something if you expect to be able to resell it for more tomorrow. So I'd not say that what people call bubbles has that much to do with being far from fundamentals, but with information being propagated that shows that the current estimate of future value is very different from the current price. If a pharma company is on trials to cure a major kind of cancer, its stock will go up. If the trials are unsuccessful, it might go all the way to zero. But that doesn't mean that there was a bubble. This is especially true with stocks, where, if you really think a price is way too high, a hedge fund can make money shorting it.
So, when calling something a bubble, we have to have some very strong reasons to do so. You could claim that the Efficient Market Hypothesis doesn't hold, even at the weakest of levels, at which point you are very, very far from mainstream economics. You can instead claim that the problem is that the market is being manipulated, and that might be the case with Bitcoin, for instance. Maybe a company is committing major fraud, and most people don't know about it, but you do have insider knowledge. That'd not be much of a bubble, just plain decepcion. You could also claim that there are major amounts of risk baked into the price, so you can expect volatility. Many would argue that the financial crisis, for instance, was really all about the Fed just not making any sense, and not reacting to a sudden increase to the demand of money.
So when it comes to bitcoin, how do you explain the bubble? My favorite is a combination of price manipulation from actors that control way too much bitcoin for a market to be all that efficient, tied to a high amount of variance in possible outcomes. If through something strange, Bitcoin actually happened to become important, then its current price is very low compared to what it should be. If it is not, then the current price is way too high. So what we see is a market that is mostly known by people who are just spending a few dollars hoping to make millions, so for them, it's a lottery ticket. Buying a lottery ticket, hand having it lose, doesn't mean that there was an asset bubble with the tickets, does it? :)
It''s not just facebook: There's plenty of large companies out there flush with cash that are not investing the money on their own base operation, but buying other people's.
It always seemed silly to me, given how bad a track record there is on acquisitions. More often than not, it's not just that the merger produces no value through synergy, but value is actually destroyed, as the bought company quickly loss independence, then talent. All you get is a brand.
In the only places where I've seen good successes is when purchasing very small organizations, where all you are really doing is paying a few people very large amounts of money to come work for you, instead of being independent. But then, why not just bite the bullet and do whatever it takes to make the right kind of candidate to come work for you?
Don't forget the major advantage in natural resources. America has historically been seen as an industrial powerhouse, but the US's can crush anyone in agriculture and resource extraction. And all that, with very low population density, so the resources per capita are insane.