The bandwidth problem is not on the way out (it's bigger than you think, but it's still small), but on the way in. It's a 1080p video stream that has to be compressed on the fly that cannot do any significant amount of buffering. Netflix already eats bandwidth for lunch, and that with compression algorithms that can run for as long as you want to optimize bandwidth use. So we get weaker compression, and we send a user 4 frames for every frame they see, so 8 times the bandwidth of Netflix for the same image quality.
So yeah, if there are data caps, they better be in the multi-terabyte a month range, or you just can't use this system at all.
Java is uncool because it moves at a glacially slow speed, and has an ecosystem full of enterprise tools that do nothing but slow us down.
The first real shock came from Ruby on Rails. I'd never use the thing for anything large or requiring much customization, but it sure showed many Java programmers how the state of the Java art, full of Spring and Hibernate, was pretty unproductive, all things considered. To write production code, you don't really need the mess of AbstractFactoryProviders that Java had become. After this, we started seeing people writing JVM languages that cut some of that madness.
So now Java has been playing catchup to Scala, Groovy and Clojure, because you have the same Write Once, Run Anywhere features, but the code is 1/3rd of the size. Even languages that try to work on closed ecosystems try to mimic that kind of style: Just look at how much Swift looks like Scala's reference-counting cousin.
Java's inability to evolve the language will remain an issue for the foreseeable future. Just look at all the things java 9 is supposed to offer: The roadmap could be sold as a cure for insomnia.
The problem with real life testing is that it's so absolutely slow you won't even go through the examples you can think of.
Simulator testing is a bit like property based testing on software. I come up with a 'test envelope' of things that could possibly happen, and let generators combine them in many ways, as to check way more options that I ever could with example based testing. Then we run a few thousand of those random scenarios every build. If there's ever a failure, it's recorded and we can reproduce it
In something like a car, your test envelope might be bigger than even in the largest property based testing system, but then you can just add that entire family of circumstances to the test.
Regular, over the air TV football is not really better for the football geeks, because camera selection is based on what is more spectacular, but misses quite a bit of action. You only get to see a wide receiver when the ball is thrown in his direction. Is he playing his best and getting beat? Is the QB just missing open receivers? Is a receiver just not trying when he is not the top option, giving away where the play is really going? Good luck getting any of that from the TV broadcast.
There is a camera that shows everything through: All 22 players, all the time. But since it's very far away, it trades bring close to the action away in exchange for great Xs and Os information.
It'd be far better to have this camera, which coaches use all the time, along with a close view of the action, but the only good way of getting close to that live is to have what an offensive coordinator has: Access to the TV broadcast, while being able to watch the game live from a relatively high vantage point, instead of down at the sidelines.
I am sure you have heard that the proper way of talking about the next half-life sequel is to call it Ricochet 2. It's the only way to get Gabe to actually tell you anything.
If there's anything wrong with starting with Java is not really the old thing about memory management: Today, many languages used in the industry are garbage collected one way or the other, yes, even in games.
However, the problem with Java is that it teaches you relatively little of what a programming language can do for you. It's a language that moves glacially slowly. It just now got basic support for lambdas. It's still about as verbose as you are going to get this side of Cobol.
So if I had to recommend a curriculum today, I'd make sure students can see the world outside of Java. Even within the JVM, Clojure, Scala and Groovy are are much nicer to work with than plain Java. One could teach some F#, or some Haskell. A key part of being a professional developer is learning new tools, so why just teach one?
I wonder if it's you that has to give back your geek card.
No, competent Java developers do not call the garbage collector at random. Or ever, really. However, there are often memory problems with Java apps that, from a user's perspective, are not really much different from a traditional C leak. What we do in JVM languages is make sure that objects are out of scope as early as possible, so that the garbage collector gets to them quickly. It's very common to see silly mistakes like making data structures grow without bound because code keeps adding to them, and never getting removed. It's not a memory leak, in the C sense, but your memory use is growing without bounds, and without doing anything useful, just the same.
There are quite a few variations of issues like that: A reference or two can make many megabytes worth of objects not get marked for deletion. If you had ever opened a Java profiler, you'd have seen that managing this kinds of memory problems is seen as just as important as figuring out what parts of the code are hogging the processor.
Many, if not all NFL teams, already issue ipads to players to hold the playbook and film clips: Before you had to hand players tapes every week, and update the playbook, which used to be a big binder where you had to switch pages in and out.
What they are talking about replaces the binders with pictures of previous plays that you can see quarterbacks check on any TV broadcast. I guess that now that it's digitized, instead of stills, they'll get a video feed from the all-22 camera, and some way for the offensive coordinator, up above, to send bookmarks to the players on the side of the field.
It takes you 3 seconds to type a secure password on a tablet? You are pretty fast. 10-12 characters, many of which require a mode change... 18 taps or so. It takes me 15 seconds to type what it'd take 2 on a real keyboard.
At the same time, I would much rather type the password every time in the tablet that my son uses than have to police the darned tablet for 15 minutes after I type my password.
There were many reasons, not just price: The Spectrum demographic was a bit older, the games were cheaper, and it was far, easier to figure out if you were buying something good like Knight Lore or the terrible Uchi Mata, because cheap. monthly magazines reviewed them: If you were old enough to buy the games, you were old enough to read the magazine first. Game magazines got tapes from the studios and publishers in time, so it's not as if you had things like the ET debacle. ET didn't hurt the industry because it was a bad game, but because enough kids actually got it.
Yes, it makes some of us cancel, but some companies still do it. Charter will call you mercilessly if you do not have a triple play package. After they managed to call me 5 times in the same week, I just got fed up and switched to another evil company, but at least one that doesn't spend all their days nagging me.
You'd be surprised if you looked at the real productivity of some of those people that have very real understanding of advanced programming concepts. I've worked, and seen code, from people who build well known functional libraries. Speak in conferences, write papers... all that stuff. But when you hand them a real life problem, they end up going for an extremely convoluted, mathematically correct solution that, when put on a real system, does not work, because some assumptions are wrong.
That doesn't mean that you can't be a good coder if you have a firm understanding of free monads. Understanding of complex, impressive CS stuff and being productive writing reliable, easy to maintain code that does what it's supposed toorthogonal to each other. Do not assume that being good at one makes you good at the other.
There's people that shit on D&D, like me, who say it not because it's an RPG, but because it's arguably the least social RPG system this side of Rolemaster. How many haven't had experiences of groups whose main focus was to try to maximize their combat efficiency, all else be damned? Then you have two games, a fine social game, where the combat people look bored, and suddenly combat, where the people that spend their days pouring over many pages of unnecessary rules enjoy themselves.
I like tabletop strategy games. I like Role playing, but D&D manages to get into the 'ugly valley' of having the worst of both worlds. If I want to play a tactical game, I play that. If I want an RPG, I look for something with a lighter combat system, or one without it altogether. D&D? Yuck.
Tech skills often just translate very well across companies, so major efforts in training will make it easier for the employee to leave. Compare that with, say, domain knowledge: Knowing what your company does better will not help you get a job that pays better elsewhere. The end result is that training is the most attractive fora company that pays extremely well and rarely loses employees: The kind of company that does NOT need to train anyone, because it becomes a top destination of their market.
Who has trouble hiring? The companies that, for other reasons, have trouble with retention (and no, it's not a money problem except in the most egregious of cases). And if those companies start training people that lack the skills, they will stay for 6-12 months and leave to the next gig at one of those more desirable companies.
In engineering, employees' knowledge translates worse across companies, so they all need to provide training, so this problem of a lack of equilibrium I described is not the first thing hiring managers will talk about.
Modern dryers offer timed settings, but they are not the most efficient: The recommended settings stop when the clothes are dry enough. This changes with the season, the specific set of clothes you put inside of it, and all that. So if you don't want to go downstairs in the worst case scenario, you will make multiple visits every so often, because you just got there too early.
So is this theoretical programmer at home, playing poker, because he doesn't like the current wages? Because if he is at a different programming job, and he switches jobs because wages went up in a different employer, there's still an opening, just in a different company.
I for one do not think there are many people refusing to get a programming job because of low wages, but your local market might be very different from mine,
Full MIT numbers are not necessarily representative, because the majors people pick in MIT are not really all that close to those found at tech companies.
It's like looking at STEM as a whole vs Software companies. There are plenty of women entering STEM field, they just tend to focus on the S or the M (pun not intended, really), instead of on the T and the E. And even in Engineering, you'll mostly find them working on biotechnology. You'll find plenty of them in companies working on genetics, but not on your typical web company.
If you want to look for discrimination, look at which specialties within computing end up having more women. Everywhere I've worked, DBAs and testers had a much higher representation of women than programming, and it's not as if most people choose to become testers instead of program, since we are still paying those jobs less, although a tester today could end up writing quite a bit of code.
People that you meet in a group that has a certain shared interest aren't necessarily going to behave the same way with people that are not part of the same group.
When it comes down to it, almost everyone ends up behaving in a regular, down to earth way, around some people. We take our barriers down, and we consider people around us equals. But when people are surrounded by those they consider 'other', or just directly inferior, behavior can change dramatically. This is a major reason some people have a much easier way through life than others: Having the capability of making other people relate to you quickly is a major skill that makes sure you only get to face the best part of people. It's the reason some minorities have it rough: The same person that is very nice to you might be pretty terrible to them. You can even see this in groups that are trying to help minorities: If they believe you are one of the oppressors, for whatever reason, you will see how they can quickly have the exact same behaviors that they accuse others of having.
This is very easy to notice if you have friends that provide extremely different first impressions than you do. It's amazing the different treatment that a geeky introvert male that has English as a second language and a white, all-american party girl get. Both get harassment, but from different people, who tend to be perfectly good people around the other one.
So if some people were nice to you, and met you at a Mensa meeting, you just can't assume that they are the same kind of people around non-Mensa members, or when they think they are being watched by their peers.
Finding bugs is not a matter of speculation, but that doesn't mean you can prove that something that already happened was caused by said bug. It's especially fun in cases like the one you describe, a stack overflow. Is it possible that a system was in an undefined state at the time of a crash? Yes. But can we prove it?
In the case of a bug that is hard to reproduce, and where we do not have a good, indisputable account of what happened before, it's easy to cause a recall, but not so easy to prove fault on a specific incident.
The fact that most people only watch a few channels doesn't really mean that a la carte would be cheaper overall.
Imagine that there are two channels. It takes a hundred bucks to keep the channel airing for a month. We have two viewers, A and B. A likes channel 1, and B likes channel 2, and they dislike the other channel. Right now, they each pay $100 to watch both channels, although they only look at one. Each channel gets paid $50 per bill.
So imagine that we switched to A la carte. Now A only subscribes to 1, and B only subscribes to 2. They channels still need the same amount of money to stay on the air, so what is the new price? subscribing to channel 1 is $100, and subscribing to channel 2 is $100 too. both channels get the same amount of money, both people pay the same bill... and they now get half the programming. Success?
So let's say that now ESPN charges $20 per subscriber. They do so, because they believe that the value they provide to the average subscriber is about $20. Let's say I don't like ESPN, Well, ESPN didn't get any less valuable, it's just that I will not pay the $20, and said $20 are going to be passed on as rate hikes to the people that want to watch the channel.
So while some people that really just watch very few, cheap channels, might get some savings, if your 17 channels include ESPN, Disney Channel, CNN, AMC and HBO, guess what? You will probably be paying a whole lot more than before, as unbundling makes every single channel more expensive, and you just happened to like 'anchor' channels that can really ask for a premium.
You must have a very different experience with buyouts than I do. I've seen a few over the years. If there are no relocations, some people stay as long as required to get the customary retention bonus, and they they all disappear en masse.
Companies have a culture. Some cultures are pretty good, others are terrible. An acquisition tends to obliterate the purchased company's culture, while bringing in part of the culture of the buyer, except that the team that remains doesn't really buy in that parent culture in the slightest.
So maybe companies aren't something to cry about, but nice relationships and a culture that is destroyed, all for what in the end is seen is a failure of an acquisition, is something that can make people sad, and for good reason.
The first google maps almost put the entire competition out of business, mostly due to their brutal UI advantage. Big map windows, instead of tiny squares. Scrolling and zooming that made sense. It was as disruptive to a market as anything else Google has ever released.
And then there's the Mixels. 5 bucks MSRP, using a subset of blocks that make them very easy to combine with each other. You even get suggestions on how to combine them from the website.
High densities in Europe are reached by going quite a bit higher than the 4 stories you are allowed to go in most of San Francisco. Most of Madrid, for instance, goes to 10-15. 5 story areas are extremely expensive old buildings where any condo goes for well over a million dollars.
Today, the PC market isn't really about pushing hardware. Remember Crysis? It sold nothing, because very few people believed they even had the rig to play it. Nobody releases for really high end hardware anymore: What you get with expensive hardware is insane resolutions. Who are the big players in PC games? The people making MOBAs, MMOs, and indies. Some rely on constant updates, which do not fare well in the console world: Valve tried to keep selling TF2 on the 360, but there was no way in hell they'd be allowed to update the game for free monthly, if not weekly. There's plenty of articles about it, look it up.
So what the PC market gives is both enhanced capabilities for constant engagement, and being able to sell your game for pennies. You'd be mad to target something like Paper's Please as a console-only game. League of Legends or Dota on consoles? yeah right. And none of those games need anything that even resembles a $1500 machine to run.
If we have to compare PC gaming to something, it's mobile games, but with far better control options, and less fear of install sizes.
Slashdot Mirror
The bandwidth problem is not on the way out (it's bigger than you think, but it's still small), but on the way in. It's a 1080p video stream that has to be compressed on the fly that cannot do any significant amount of buffering. Netflix already eats bandwidth for lunch, and that with compression algorithms that can run for as long as you want to optimize bandwidth use. So we get weaker compression, and we send a user 4 frames for every frame they see, so 8 times the bandwidth of Netflix for the same image quality.
So yeah, if there are data caps, they better be in the multi-terabyte a month range, or you just can't use this system at all.
Java is uncool because it moves at a glacially slow speed, and has an ecosystem full of enterprise tools that do nothing but slow us down.
The first real shock came from Ruby on Rails. I'd never use the thing for anything large or requiring much customization, but it sure showed many Java programmers how the state of the Java art, full of Spring and Hibernate, was pretty unproductive, all things considered. To write production code, you don't really need the mess of AbstractFactoryProviders that Java had become. After this, we started seeing people writing JVM languages that cut some of that madness.
So now Java has been playing catchup to Scala, Groovy and Clojure, because you have the same Write Once, Run Anywhere features, but the code is 1/3rd of the size. Even languages that try to work on closed ecosystems try to mimic that kind of style: Just look at how much Swift looks like Scala's reference-counting cousin.
Java's inability to evolve the language will remain an issue for the foreseeable future. Just look at all the things java 9 is supposed to offer: The roadmap could be sold as a cure for insomnia.
The problem with real life testing is that it's so absolutely slow you won't even go through the examples you can think of.
Simulator testing is a bit like property based testing on software. I come up with a 'test envelope' of things that could possibly happen, and let generators combine them in many ways, as to check way more options that I ever could with example based testing. Then we run a few thousand of those random scenarios every build. If there's ever a failure, it's recorded and we can reproduce it
In something like a car, your test envelope might be bigger than even in the largest property based testing system, but then you can just add that entire family of circumstances to the test.
Regular, over the air TV football is not really better for the football geeks, because camera selection is based on what is more spectacular, but misses quite a bit of action. You only get to see a wide receiver when the ball is thrown in his direction. Is he playing his best and getting beat? Is the QB just missing open receivers? Is a receiver just not trying when he is not the top option, giving away where the play is really going? Good luck getting any of that from the TV broadcast.
There is a camera that shows everything through: All 22 players, all the time. But since it's very far away, it trades bring close to the action away in exchange for great Xs and Os information.
It'd be far better to have this camera, which coaches use all the time, along with a close view of the action, but the only good way of getting close to that live is to have what an offensive coordinator has: Access to the TV broadcast, while being able to watch the game live from a relatively high vantage point, instead of down at the sidelines.
I am sure you have heard that the proper way of talking about the next half-life sequel is to call it Ricochet 2. It's the only way to get Gabe to actually tell you anything.
If there's anything wrong with starting with Java is not really the old thing about memory management: Today, many languages used in the industry are garbage collected one way or the other, yes, even in games.
However, the problem with Java is that it teaches you relatively little of what a programming language can do for you. It's a language that moves glacially slowly. It just now got basic support for lambdas. It's still about as verbose as you are going to get this side of Cobol.
So if I had to recommend a curriculum today, I'd make sure students can see the world outside of Java. Even within the JVM, Clojure, Scala and Groovy are are much nicer to work with than plain Java. One could teach some F#, or some Haskell. A key part of being a professional developer is learning new tools, so why just teach one?
I wonder if it's you that has to give back your geek card.
No, competent Java developers do not call the garbage collector at random. Or ever, really. However, there are often memory problems with Java apps that, from a user's perspective, are not really much different from a traditional C leak. What we do in JVM languages is make sure that objects are out of scope as early as possible, so that the garbage collector gets to them quickly. It's very common to see silly mistakes like making data structures grow without bound because code keeps adding to them, and never getting removed. It's not a memory leak, in the C sense, but your memory use is growing without bounds, and without doing anything useful, just the same.
There are quite a few variations of issues like that: A reference or two can make many megabytes worth of objects not get marked for deletion. If you had ever opened a Java profiler, you'd have seen that managing this kinds of memory problems is seen as just as important as figuring out what parts of the code are hogging the processor.
Many, if not all NFL teams, already issue ipads to players to hold the playbook and film clips: Before you had to hand players tapes every week, and update the playbook, which used to be a big binder where you had to switch pages in and out.
What they are talking about replaces the binders with pictures of previous plays that you can see quarterbacks check on any TV broadcast. I guess that now that it's digitized, instead of stills, they'll get a video feed from the all-22 camera, and some way for the offensive coordinator, up above, to send bookmarks to the players on the side of the field.
It takes you 3 seconds to type a secure password on a tablet? You are pretty fast. 10-12 characters, many of which require a mode change... 18 taps or so. It takes me 15 seconds to type what it'd take 2 on a real keyboard.
At the same time, I would much rather type the password every time in the tablet that my son uses than have to police the darned tablet for 15 minutes after I type my password.
There were many reasons, not just price: The Spectrum demographic was a bit older, the games were cheaper, and it was far, easier to figure out if you were buying something good like Knight Lore or the terrible Uchi Mata, because cheap. monthly magazines reviewed them: If you were old enough to buy the games, you were old enough to read the magazine first. Game magazines got tapes from the studios and publishers in time, so it's not as if you had things like the ET debacle. ET didn't hurt the industry because it was a bad game, but because enough kids actually got it.
Yes, it makes some of us cancel, but some companies still do it. Charter will call you mercilessly if you do not have a triple play package. After they managed to call me 5 times in the same week, I just got fed up and switched to another evil company, but at least one that doesn't spend all their days nagging me.
You'd be surprised if you looked at the real productivity of some of those people that have very real understanding of advanced programming concepts. I've worked, and seen code, from people who build well known functional libraries. Speak in conferences, write papers... all that stuff. But when you hand them a real life problem, they end up going for an extremely convoluted, mathematically correct solution that, when put on a real system, does not work, because some assumptions are wrong.
That doesn't mean that you can't be a good coder if you have a firm understanding of free monads. Understanding of complex, impressive CS stuff and being productive writing reliable, easy to maintain code that does what it's supposed toorthogonal to each other. Do not assume that being good at one makes you good at the other.
There's people that shit on D&D, like me, who say it not because it's an RPG, but because it's arguably the least social RPG system this side of Rolemaster. How many haven't had experiences of groups whose main focus was to try to maximize their combat efficiency, all else be damned? Then you have two games, a fine social game, where the combat people look bored, and suddenly combat, where the people that spend their days pouring over many pages of unnecessary rules enjoy themselves.
I like tabletop strategy games. I like Role playing, but D&D manages to get into the 'ugly valley' of having the worst of both worlds. If I want to play a tactical game, I play that. If I want an RPG, I look for something with a lighter combat system, or one without it altogether. D&D? Yuck.
Tech skills often just translate very well across companies, so major efforts in training will make it easier for the employee to leave. Compare that with, say, domain knowledge: Knowing what your company does better will not help you get a job that pays better elsewhere. The end result is that training is the most attractive fora company that pays extremely well and rarely loses employees: The kind of company that does NOT need to train anyone, because it becomes a top destination of their market.
Who has trouble hiring? The companies that, for other reasons, have trouble with retention (and no, it's not a money problem except in the most egregious of cases). And if those companies start training people that lack the skills, they will stay for 6-12 months and leave to the next gig at one of those more desirable companies.
In engineering, employees' knowledge translates worse across companies, so they all need to provide training, so this problem of a lack of equilibrium I described is not the first thing hiring managers will talk about.
Modern dryers offer timed settings, but they are not the most efficient: The recommended settings stop when the clothes are dry enough. This changes with the season, the specific set of clothes you put inside of it, and all that. So if you don't want to go downstairs in the worst case scenario, you will make multiple visits every so often, because you just got there too early.
So is this theoretical programmer at home, playing poker, because he doesn't like the current wages? Because if he is at a different programming job, and he switches jobs because wages went up in a different employer, there's still an opening, just in a different company.
I for one do not think there are many people refusing to get a programming job because of low wages, but your local market might be very different from mine,
Full MIT numbers are not necessarily representative, because the majors people pick in MIT are not really all that close to those found at tech companies.
It's like looking at STEM as a whole vs Software companies. There are plenty of women entering STEM field, they just tend to focus on the S or the M (pun not intended, really), instead of on the T and the E. And even in Engineering, you'll mostly find them working on biotechnology. You'll find plenty of them in companies working on genetics, but not on your typical web company.
If you want to look for discrimination, look at which specialties within computing end up having more women. Everywhere I've worked, DBAs and testers had a much higher representation of women than programming, and it's not as if most people choose to become testers instead of program, since we are still paying those jobs less, although a tester today could end up writing quite a bit of code.
People that you meet in a group that has a certain shared interest aren't necessarily going to behave the same way with people that are not part of the same group.
When it comes down to it, almost everyone ends up behaving in a regular, down to earth way, around some people. We take our barriers down, and we consider people around us equals. But when people are surrounded by those they consider 'other', or just directly inferior, behavior can change dramatically. This is a major reason some people have a much easier way through life than others: Having the capability of making other people relate to you quickly is a major skill that makes sure you only get to face the best part of people. It's the reason some minorities have it rough: The same person that is very nice to you might be pretty terrible to them. You can even see this in groups that are trying to help minorities: If they believe you are one of the oppressors, for whatever reason, you will see how they can quickly have the exact same behaviors that they accuse others of having.
This is very easy to notice if you have friends that provide extremely different first impressions than you do. It's amazing the different treatment that a geeky introvert male that has English as a second language and a white, all-american party girl get. Both get harassment, but from different people, who tend to be perfectly good people around the other one.
So if some people were nice to you, and met you at a Mensa meeting, you just can't assume that they are the same kind of people around non-Mensa members, or when they think they are being watched by their peers.
Finding bugs is not a matter of speculation, but that doesn't mean you can prove that something that already happened was caused by said bug. It's especially fun in cases like the one you describe, a stack overflow. Is it possible that a system was in an undefined state at the time of a crash? Yes. But can we prove it?
In the case of a bug that is hard to reproduce, and where we do not have a good, indisputable account of what happened before, it's easy to cause a recall, but not so easy to prove fault on a specific incident.
The fact that most people only watch a few channels doesn't really mean that a la carte would be cheaper overall.
Imagine that there are two channels. It takes a hundred bucks to keep the channel airing for a month. We have two viewers, A and B. A likes channel 1, and B likes channel 2, and they dislike the other channel. Right now, they each pay $100 to watch both channels, although they only look at one. Each channel gets paid $50 per bill.
So imagine that we switched to A la carte. Now A only subscribes to 1, and B only subscribes to 2. They channels still need the same amount of money to stay on the air, so what is the new price? subscribing to channel 1 is $100, and subscribing to channel 2 is $100 too. both channels get the same amount of money, both people pay the same bill... and they now get half the programming. Success?
So let's say that now ESPN charges $20 per subscriber. They do so, because they believe that the value they provide to the average subscriber is about $20. Let's say I don't like ESPN, Well, ESPN didn't get any less valuable, it's just that I will not pay the $20, and said $20 are going to be passed on as rate hikes to the people that want to watch the channel.
So while some people that really just watch very few, cheap channels, might get some savings, if your 17 channels include ESPN, Disney Channel, CNN, AMC and HBO, guess what? You will probably be paying a whole lot more than before, as unbundling makes every single channel more expensive, and you just happened to like 'anchor' channels that can really ask for a premium.
You must have a very different experience with buyouts than I do. I've seen a few over the years. If there are no relocations, some people stay as long as required to get the customary retention bonus, and they they all disappear en masse.
Companies have a culture. Some cultures are pretty good, others are terrible. An acquisition tends to obliterate the purchased company's culture, while bringing in part of the culture of the buyer, except that the team that remains doesn't really buy in that parent culture in the slightest.
So maybe companies aren't something to cry about, but nice relationships and a culture that is destroyed, all for what in the end is seen is a failure of an acquisition, is something that can make people sad, and for good reason.
The first google maps almost put the entire competition out of business, mostly due to their brutal UI advantage. Big map windows, instead of tiny squares. Scrolling and zooming that made sense. It was as disruptive to a market as anything else Google has ever released.
And then there's the Mixels. 5 bucks MSRP, using a subset of blocks that make them very easy to combine with each other. You even get suggestions on how to combine them from the website.
High densities in Europe are reached by going quite a bit higher than the 4 stories you are allowed to go in most of San Francisco. Most of Madrid, for instance, goes to 10-15. 5 story areas are extremely expensive old buildings where any condo goes for well over a million dollars.
The 90s called, they want their arguments back.
Today, the PC market isn't really about pushing hardware. Remember Crysis? It sold nothing, because very few people believed they even had the rig to play it. Nobody releases for really high end hardware anymore: What you get with expensive hardware is insane resolutions. Who are the big players in PC games? The people making MOBAs, MMOs, and indies. Some rely on constant updates, which do not fare well in the console world: Valve tried to keep selling TF2 on the 360, but there was no way in hell they'd be allowed to update the game for free monthly, if not weekly. There's plenty of articles about it, look it up.
So what the PC market gives is both enhanced capabilities for constant engagement, and being able to sell your game for pennies. You'd be mad to target something like Paper's Please as a console-only game. League of Legends or Dota on consoles? yeah right. And none of those games need anything that even resembles a $1500 machine to run.
If we have to compare PC gaming to something, it's mobile games, but with far better control options, and less fear of install sizes.