I don't believe AR will become Apple's Metro. First, Apple is often isn't the first ones to push risky new technologies, so I have my doubts they'll have anything ready for shipping by next year. They watch what others do, then try to do it with more polish and style. Second, even if they did some AR-focused product, I don't believe Apple is so stupid as to think AR should replace the fundamental iOS UI paradigm.
Whatever mistake removing the phone jack may (or may not) be, and however overhyped AR may be, I think it will probably be an order of magnitude less terrible than what was inflicted on Windows users with Windows 8. Windows 10 *finally* got the "modern/metro" integration mostly correct, but burned through a lot of user goodwill in other areas (privacy, intrusiveness, forced upgrades, etc).
It's not just a thing in the US. However, perhaps you didn't have to deal with tipping because they simply added an extra 10 or 15% to the bill. There are some non-tipping cultures such as China, Japan, S Korea, New Zealand, Australia, etc, but I'm not sure they outnumber tipping cultures.
But when someone pulls out a phone these days, we are increasingly accepting that they must be doing something important (e.g., responding to a critical message) and also can " multitask" (hint -- that doesn't really work well).
Ah, no, I'd still be irritated. If a family member has an emergency, they'll call. Otherwise, there's no reason for you to be constantly checking your phone. That's just compulsive behavior, and I still think it's rude to do it in front of company that you're engaged with. Or supposed to be, I guess. Am I old-fashioned? Maybe so, if that's the new norm.
Technology can certainly become a distraction to your life and relations if you let it. People have ruined their lives because of addictions to online games - more notably when they were new, but I'm sure it still happens. Same with social media, no doubt, and lots of other things.
All things in moderation, as they say. I still think it's pretty good advice, and applies to just about any new disruptive tech that comes along. That's because it's human nature we're dealing with, and our frequent tendency to get obsessed to the point of distraction with interesting new things, if we let ourselves.
* The term "love" shall in no way be construed to contain any positive connotation or endorsement, nor does it imply any emotional attachment to a faceless corporation who only cares only about sucking every last dollar from their customers.
These guys may not be exactly unique in eschewing DRM, but it's great that we see more people talking about it, and that a lack of DRM is a positive marketing bullet point. Indie game developers like me can simply make an executive decision about releasing multiplatform and without DRM since we have fewer strings attached. It would be great, though, if larger companies and publishers were to join the party as well, not that I'm holding my breath.
It's certainly true that you'll always have a piece of your revenue pie cut out by piracy, often a fairly large piece, but I still think that the ill will generated by DRM isn't worth it. Instead, focus on making excellent games, and figure out a way to reward your paying customers instead of punishing them. Try to win over your current non-paying non-customers and convert them into paying customers.
Obviously, it's not truly "unlimited" (hint: nothing is), but
Then maybe they should stop using that word in their advertisement of services. Most other industries get called out if they outright lie in advertisements. Pretty sure there are even laws about it. Why the special pass for carriers and ISPs?
It's not that either. Or at least, that's not the whole answer. I think a large factor is that many people no longer need a PC at all to do basic personal computing, or take part in the information age. A smartphone or tablet will do just fine for many basic computing and communication tasks, and those are an order of magnitude easier for normal people to use.
PCs are edging their way back to being gaming, specialist, and business machines. They're not dying, just finding a more specialized niche. People who are predicting the "death" of the PC are off the mark. They'll decline to a point, then stabilize as a much smaller industry than in its heyday, with many PC manufacturers consolidating, diversifying, or going out of business. There are still many tasks that will continue to require a full screen display and comfortable keyboard, and PCs still have an advantage as one of the few remaining open platforms.
Of course, we're already seeing the market plateau with tablets, and I think soon smartphones will be in the same boat as technology matures, the market is saturated, and so people have less reason to buy a new phone each year or two, eventually holding onto them for three to six years or so (probably no longer than that due to simple wear and tear).
Let's look at those transportation methods in fatalities per billion hours traveled:
Bus - 11 Rail - 30 Air - 30 Water - 50 Van - 60 Car - 130 Foot - 220 Bicycle - 550 Motorcycle - 4,840 Space Shuttle - 438,019
Now, let's consider how many hours we spend each day in each of these activities. I'd guess I'm in the car an average of perhaps 1 1/2 hours per day. Since nothing else comes close (assuming treadmills don't count as "walking"), I'm at FAR more risk than dying in a car crash than any other transportation method by a very large margin.
Lies, damn lies, and statistics. According to your statistics, the space shuttle is only slightly more dangerous than driving in a car and less dangerous than a ferry, which is obvious nonsense.
I know the USA has much more empty space between travel points, but still. For most of the folks in the cities it shouldn't be a big deal to drive electric.
That empty space is a real issue. When I was in college, it was 350 miles (560 km) between there and home, and this was a state college. I regularly made the trip on long weekends and holidays. No electric car sold today that I'm aware of has such a range.
These days, my longest round trip is about 120 miles, so an electric car would makes sense. In fact, my next car will very likely be electric. But my fear is that overzealous advocates will neglect to take others' needs into consideration. Just because one person's lifestyle works without a car or with a range-limited e-car doesn't mean its practical for everyone.
Also, consider that car rentals will be in peak demand during holidays, so you'll have to reserve far in advance and pay a premium, just like you do for holiday flights.
I used to use noscript (which sort of works like an ad-blocker itself), and it was getting to be too much of a pain, so switched to uBlock Origin (which also blocks known malware domains by default as a bonus). Even though scripting is used to perform the infection, these days, disabling scripting just isn't feasible for many modern websites. It seems like it's scripting in ads that are the most typical delivery vector, and even then, it often depends on known, unpatched exploits (like Flash or Java plugins) or simple social engineering. So, just blocking the ads is probably enough, unless you're a "belt and suspenders" type. Good for you if you're willing to put up the inconvenience of trying to selectively unblock domains until a site works again, but if you're making the suggestion for normal users, I'd recommend just the ad-blocker.
Incidentally, I really have nothing against ads themselves, unless they're intrusive and obnoxious (they were edging more and more this way, unfortunately). I block ads only because they're potentially dangerous. Once the industry figures out a way to create bulletproof-safe ads, I'll consider selectively unblocking sites I wish to support and which are useful or entertaining to me.
It's partly that, perhaps, but I think it's also something more. I think that science fiction demand something unique of a reader that other genres do not. It requires a larger leap of imagination in order to allow the author to create an entire world, and quite possibly a new society to go along with it, with different rules and conventions. They insist that a read be able to take that leap and make that world their own for the duration of the story.
Sadly, I think this is a leap too far for many people, who consider "playing make-believe", even in literary form, beneath them, somehow childish or undignified. It pulls you out of your comfortable knowledge of the world and everything in it, and forces you to relearn the universe and its rules again, which may be an uncomfortable process for some. And this is perhaps even more true for fantasy than science fiction, because at least science fiction can still take place in our own universe where the same physical laws still apply, however speculative it is with future technology.
Removing math from programing? Is he/she serious? It's required to understand the functions and computer languages. Without it you can't properly make code!
I'd argue that any math beyond basic arithmetic and logic you require during programming is likely application-domain specific. Early programmers were mathematicians and physicists because they were using computers to solve hard math and physics programs. I've found that many programmers seem to have a really hard time separating the notion of programming itself from the applications which they are developing. There are no calculus problems I have to solve on a daily basis in order to write code. If I do use advanced math, it's for the benefit of the specific problem I'm trying to solve with my code - not a part of the coding process itself.
Computer science is more about the art and science of breaking large, complex problems into bite-sized tasks that can be solved piecemeal, which often requires an interesting mix of logical reasoning and creative puzzle-solving. I think understanding the classic patterns from the gang of four, fundamental data structures, and how computers work at both hardware and abstract levels are far more useful than classical mathematics to professional programmers. Many have suggested that formal logic courses would be more beneficial, which I could agree with, although I think most of that can be covered in early programming classes as well when dealing with boolean logic and bit-level math.
Personally, I almost never use Calculus-level math, but Linear Algebra and matrix math is crucial for 3D math (videogames). For others, perhaps business math and accounting would be more useful. For engineering specific software, you'd likely need more physics and advanced math. The level of math required tends to be entirely based on what type of programming you do.
Ehh, a first-person shooter is not really all that great a test for AI. Being a videogame programmer, and one who has programmed his share of AI in commercial videogames, the trick is not to create unbeatable AI, but to create an interesting experience for the player. Granted, we use a lot of internal data structures to assist the AI (like for navigation), and we obviously approach things from a completely different angle, but we also have to drastically handicap the AI's responsiveness and aim in shooter-type games.
Remember, it's trivial for a computer to paint a bulls-eye between your eyes from 500 yards out with a sniper rifle no matter how you're moving or hiding. It's still reasonably easy even with true projectiles, as the AI can calculate perfect flight trajectories so that rocket will precisely intercept a moving target. An AI can't get disoriented, or confused, and has near-instant reflexes that no human can match.
One trick I've used for shooter bots is to incorporate virtual springs attached to the bot's targets, helping to throw off their aim according to how the target is moving. You can also dynamically adjust the target spring tension or based on other factors, like difficulty scaling, whether the AI agent is running, jumping (throwing off his own aim), etc. That sort of thing, along with adding blind spots, artificial reaction times, intentional mistakes, and so on, are the things you have to do to keep the bots from kicking the crap out of human players just because they could instantly headshot you from across the map otherwise.
Don't get me wrong... this is a neat little project. But beating humans in a shooter where fast reflexes and perfect aim dominate isn't really the end-all and be-all of AI tests, because our strengths and weakness are in different areas than for computer-based opponents.
Oh... I just thought that was a quaint English street accent, soon to be corrected by a snooty English bachelor, and followed by some rousing singing and dancing.
What would have happened, had it reached an unexpected obstacle, is that it would have just stopped and waited patiently until humans intervened. That's the smart thing for software to do, rather than try to get clever about a situation it doesn't understand. The issue would be reported, the manufacture would pore over the sensor and log data, the software or maps would be updated, and that particular issue would likely be avoided in the future.
I think most people would acknowledge that humans are much better at improvising and problem-solving in unexpected situations than computers are. Computers are much better, however, in performing repetitive, pre-programmed tasks, or reacting to navigational events extremely quickly.
I've never figured out that "40 year old analog technology" angle. My Mark-1 ears are also 40 year old analogy technology, so I think they match up just fine.
That's actually how my interprocess communication library handles the details underneath the interface (the Windows FileMapping API). And yep, it's extremely fast.
I haven't tried managed C++, but it sounds interesting (if I hadn't already done all the work).
I'm using modern C++ everywhere, but I still haven't found the transition to a C-style interface too onerous in most cases. As you surmised, the most awkward sections tend to be when dealing with C++ types passed around at the interface level. My typical approach is to transform the data into a structure that works in the managed code. For instance, my engine works natively with UTF-8 strings, so I need to convert between UTF-8 and 16 for each string passed. Sort of a pain, yes, but it's just a quick conversion function, and I haven't found the performance to be that bad in my case.
Part of the complexity of my system is that I not only use managed to native code interop, but I also have to transmit a lot of data across a process boundary as well. The native part of the editor window that shows the rendered game view is isolated in a separate process, so that any problems or crashes in it don't bring down or hang the main editor. As such, the nature of this system lends itself to simpler C-style interfaces anyhow, since I have to serialize everything into primitive data streams and re-interpret all those commands and data in the other process. That means the data has to be transformed into a serializable format at least once anyhow.
HDDs still make sense for local bulk storage requirements, where SSDs would not only be much more expensive by comparison, their speed would be largely wasted, since most of the time their job is just to store large amounts of data passively. It's pretty common for small businesses or specialist hobbyists to make use of a NAS with lots of local bulk storage configured in a RAID, then use a cloud-based service as backup. That's how my own home-based business is set up, in fact. Since I need lots of disk space, but don't typically work directly off the NAS, price per GB is the most critical factor.
I agree that HDDs will eventually be completely replaced, but that's only when the price per GB and capacity of SSDs gets reasonably close to HDDs. The gap is closing, but it's still nowhere near at the moment.
I had to explain the same thing to my mom, who was concerned about how we were "handing over control of the internet". I told her that this was sort of like handing control over the entity that assigns unique telephone numbers to people, but it doesn't control the phone lines themselves.
Besides which, the internet is somewhat resistant to change of *any* sort, as evidenced by the extremely slow adoption of things like IPv6 and DNSSEC, both of which would be very useful, but simple mass inertial keeps adoption rates down. So, any radical changes by these bodies would likely just be ignored not only for ideological reasons, but for practical ones as well.
I also do this all the time between my C# (tools) code and C++ (game engine) code, and I've never found it constraining, although it's certainly tedious to recreate all the APIs in C. Creating a C-style interface for just about any C++ objects is reasonably straightforward if you break it down into handle (address of object) + method. As for exceptions, game development generally doesn't use them (in native code), but yes, that would require each native method to wrap the API function in a try-catch block, then pass along errors as a C-style error code.
If performance is an issue, then it may be a sign that your interop API may be a bit too fine grained, and needs a mechanism to batch calls a bit, perhaps by moving a bit of logic down into native code so you can make fewer, more meaningful interop calls. Performance work is, unfortunately, often diametrically opposed to clean design.
Yeah, at the time, the thought of needing more than four billion internet addresses probably seemed a bit ludicrous when it was still mostly just government and university mainframes connecting. That number must have seemed like a nearly never-ending well, especially seeing how generously it was initially carved up into massive blocks. Some of the earliest corporations and universities to receive allocations still have a relatively ridiculous number of Class A blocks allocated addresses (16+ million).
We'd probably still have plenty of addresses were those initial blocks handed out a bit more judiciously, but again, part of that was done, if I understand correctly, for simplicity of routing. It's easy to criticize with the hindsight of today's hardware and needs, but those early computers were incredibly restrained on memory and CPU speeds. Even a 64-bit address would have been seen as doubling memory requirements of routing hardware for no good reason.
Agreed. A lot of us envisioned these sorts of "intelligent agents" many years ago, but I think we always envisioned they'd be local agents, or under our control somehow. Probably a bit naive, I guess.
Even so, the problem with using a local agent is that it would be difficult to automatically synchronize this information across all your devices. That's the benefit of a cloud-based service. The downside? Someone else has complete access to all the most intimate details of your life. And what privacy guarantees do we have? A "we promise" statement from the company that they won't abuse that power. Nevermind that all that data is a virtual goldmine to advertising agencies... I'm sure we can trust them.
I think that this could be done locally (and share an encrypted database in a service like Dropbox, etc), but there's no incentive for a corporation NOT to keep all that personal data in their own cloud. They'd have to work harder to cut out their own ecosystem and protect the user's privacy. And frankly, it would be harder for the end-user to use, and less convenient than using Cortana, Siri, Alexa, or Google's bots. It would be tough for such a system to gain widespread adoption. And we've seen, via Linux as a desktop OS, that simply being free and open is NOT enough to drive mass adoption.
Aaaaand... like an idiot, I failed to notice that this information is right there in the summary. How often does one read TFA and fail to read the summary? That has to count for something, right?
I don't believe AR will become Apple's Metro. First, Apple is often isn't the first ones to push risky new technologies, so I have my doubts they'll have anything ready for shipping by next year. They watch what others do, then try to do it with more polish and style. Second, even if they did some AR-focused product, I don't believe Apple is so stupid as to think AR should replace the fundamental iOS UI paradigm.
Whatever mistake removing the phone jack may (or may not) be, and however overhyped AR may be, I think it will probably be an order of magnitude less terrible than what was inflicted on Windows users with Windows 8. Windows 10 *finally* got the "modern/metro" integration mostly correct, but burned through a lot of user goodwill in other areas (privacy, intrusiveness, forced upgrades, etc).
You don't realize how many drivers you come into contact with in a day.
I'm pretty sure that, on average, I come into contact with zero drivers a day. Sheesh, how bad a driver are you?
It's not just a thing in the US. However, perhaps you didn't have to deal with tipping because they simply added an extra 10 or 15% to the bill. There are some non-tipping cultures such as China, Japan, S Korea, New Zealand, Australia, etc, but I'm not sure they outnumber tipping cultures.
But when someone pulls out a phone these days, we are increasingly accepting that they must be doing something important (e.g., responding to a critical message) and also can " multitask" (hint -- that doesn't really work well).
Ah, no, I'd still be irritated. If a family member has an emergency, they'll call. Otherwise, there's no reason for you to be constantly checking your phone. That's just compulsive behavior, and I still think it's rude to do it in front of company that you're engaged with. Or supposed to be, I guess. Am I old-fashioned? Maybe so, if that's the new norm.
Technology can certainly become a distraction to your life and relations if you let it. People have ruined their lives because of addictions to online games - more notably when they were new, but I'm sure it still happens. Same with social media, no doubt, and lots of other things.
All things in moderation, as they say. I still think it's pretty good advice, and applies to just about any new disruptive tech that comes along. That's because it's human nature we're dealing with, and our frequent tendency to get obsessed to the point of distraction with interesting new things, if we let ourselves.
Yeah, I love* the way they do that.
* The term "love" shall in no way be construed to contain any positive connotation or endorsement, nor does it imply any emotional attachment to a faceless corporation who only cares only about sucking every last dollar from their customers.
These guys may not be exactly unique in eschewing DRM, but it's great that we see more people talking about it, and that a lack of DRM is a positive marketing bullet point. Indie game developers like me can simply make an executive decision about releasing multiplatform and without DRM since we have fewer strings attached. It would be great, though, if larger companies and publishers were to join the party as well, not that I'm holding my breath.
It's certainly true that you'll always have a piece of your revenue pie cut out by piracy, often a fairly large piece, but I still think that the ill will generated by DRM isn't worth it. Instead, focus on making excellent games, and figure out a way to reward your paying customers instead of punishing them. Try to win over your current non-paying non-customers and convert them into paying customers.
Obviously, it's not truly "unlimited" (hint: nothing is), but
Then maybe they should stop using that word in their advertisement of services. Most other industries get called out if they outright lie in advertisements. Pretty sure there are even laws about it. Why the special pass for carriers and ISPs?
It's not that either. Or at least, that's not the whole answer. I think a large factor is that many people no longer need a PC at all to do basic personal computing, or take part in the information age. A smartphone or tablet will do just fine for many basic computing and communication tasks, and those are an order of magnitude easier for normal people to use.
PCs are edging their way back to being gaming, specialist, and business machines. They're not dying, just finding a more specialized niche. People who are predicting the "death" of the PC are off the mark. They'll decline to a point, then stabilize as a much smaller industry than in its heyday, with many PC manufacturers consolidating, diversifying, or going out of business. There are still many tasks that will continue to require a full screen display and comfortable keyboard, and PCs still have an advantage as one of the few remaining open platforms.
Of course, we're already seeing the market plateau with tablets, and I think soon smartphones will be in the same boat as technology matures, the market is saturated, and so people have less reason to buy a new phone each year or two, eventually holding onto them for three to six years or so (probably no longer than that due to simple wear and tear).
"Per billion mile" is a stupid way to measure safety in practical terms. We don't measure our lives in miles or kilometers. We measure them using time.
Let's look at those transportation methods in fatalities per billion hours traveled:
Bus - 11
Rail - 30
Air - 30
Water - 50
Van - 60
Car - 130
Foot - 220
Bicycle - 550
Motorcycle - 4,840
Space Shuttle - 438,019
Now, let's consider how many hours we spend each day in each of these activities. I'd guess I'm in the car an average of perhaps 1 1/2 hours per day. Since nothing else comes close (assuming treadmills don't count as "walking"), I'm at FAR more risk than dying in a car crash than any other transportation method by a very large margin.
Lies, damn lies, and statistics. According to your statistics, the space shuttle is only slightly more dangerous than driving in a car and less dangerous than a ferry, which is obvious nonsense.
I know the USA has much more empty space between travel points, but still. For most of the folks in the cities it shouldn't be a big deal to drive electric.
That empty space is a real issue. When I was in college, it was 350 miles (560 km) between there and home, and this was a state college. I regularly made the trip on long weekends and holidays. No electric car sold today that I'm aware of has such a range.
These days, my longest round trip is about 120 miles, so an electric car would makes sense. In fact, my next car will very likely be electric. But my fear is that overzealous advocates will neglect to take others' needs into consideration. Just because one person's lifestyle works without a car or with a range-limited e-car doesn't mean its practical for everyone.
Also, consider that car rentals will be in peak demand during holidays, so you'll have to reserve far in advance and pay a premium, just like you do for holiday flights.
I used to use noscript (which sort of works like an ad-blocker itself), and it was getting to be too much of a pain, so switched to uBlock Origin (which also blocks known malware domains by default as a bonus). Even though scripting is used to perform the infection, these days, disabling scripting just isn't feasible for many modern websites. It seems like it's scripting in ads that are the most typical delivery vector, and even then, it often depends on known, unpatched exploits (like Flash or Java plugins) or simple social engineering. So, just blocking the ads is probably enough, unless you're a "belt and suspenders" type. Good for you if you're willing to put up the inconvenience of trying to selectively unblock domains until a site works again, but if you're making the suggestion for normal users, I'd recommend just the ad-blocker.
Incidentally, I really have nothing against ads themselves, unless they're intrusive and obnoxious (they were edging more and more this way, unfortunately). I block ads only because they're potentially dangerous. Once the industry figures out a way to create bulletproof-safe ads, I'll consider selectively unblocking sites I wish to support and which are useful or entertaining to me.
It's partly that, perhaps, but I think it's also something more. I think that science fiction demand something unique of a reader that other genres do not. It requires a larger leap of imagination in order to allow the author to create an entire world, and quite possibly a new society to go along with it, with different rules and conventions. They insist that a read be able to take that leap and make that world their own for the duration of the story.
Sadly, I think this is a leap too far for many people, who consider "playing make-believe", even in literary form, beneath them, somehow childish or undignified. It pulls you out of your comfortable knowledge of the world and everything in it, and forces you to relearn the universe and its rules again, which may be an uncomfortable process for some. And this is perhaps even more true for fantasy than science fiction, because at least science fiction can still take place in our own universe where the same physical laws still apply, however speculative it is with future technology.
Removing math from programing?
Is he/she serious? It's required to understand the functions and computer languages. Without it you can't properly make code!
I'd argue that any math beyond basic arithmetic and logic you require during programming is likely application-domain specific. Early programmers were mathematicians and physicists because they were using computers to solve hard math and physics programs. I've found that many programmers seem to have a really hard time separating the notion of programming itself from the applications which they are developing. There are no calculus problems I have to solve on a daily basis in order to write code. If I do use advanced math, it's for the benefit of the specific problem I'm trying to solve with my code - not a part of the coding process itself.
Computer science is more about the art and science of breaking large, complex problems into bite-sized tasks that can be solved piecemeal, which often requires an interesting mix of logical reasoning and creative puzzle-solving. I think understanding the classic patterns from the gang of four, fundamental data structures, and how computers work at both hardware and abstract levels are far more useful than classical mathematics to professional programmers. Many have suggested that formal logic courses would be more beneficial, which I could agree with, although I think most of that can be covered in early programming classes as well when dealing with boolean logic and bit-level math.
Personally, I almost never use Calculus-level math, but Linear Algebra and matrix math is crucial for 3D math (videogames). For others, perhaps business math and accounting would be more useful. For engineering specific software, you'd likely need more physics and advanced math. The level of math required tends to be entirely based on what type of programming you do.
Ehh, a first-person shooter is not really all that great a test for AI. Being a videogame programmer, and one who has programmed his share of AI in commercial videogames, the trick is not to create unbeatable AI, but to create an interesting experience for the player. Granted, we use a lot of internal data structures to assist the AI (like for navigation), and we obviously approach things from a completely different angle, but we also have to drastically handicap the AI's responsiveness and aim in shooter-type games.
Remember, it's trivial for a computer to paint a bulls-eye between your eyes from 500 yards out with a sniper rifle no matter how you're moving or hiding. It's still reasonably easy even with true projectiles, as the AI can calculate perfect flight trajectories so that rocket will precisely intercept a moving target. An AI can't get disoriented, or confused, and has near-instant reflexes that no human can match.
One trick I've used for shooter bots is to incorporate virtual springs attached to the bot's targets, helping to throw off their aim according to how the target is moving. You can also dynamically adjust the target spring tension or based on other factors, like difficulty scaling, whether the AI agent is running, jumping (throwing off his own aim), etc. That sort of thing, along with adding blind spots, artificial reaction times, intentional mistakes, and so on, are the things you have to do to keep the bots from kicking the crap out of human players just because they could instantly headshot you from across the map otherwise.
Don't get me wrong... this is a neat little project. But beating humans in a shooter where fast reflexes and perfect aim dominate isn't really the end-all and be-all of AI tests, because our strengths and weakness are in different areas than for computer-based opponents.
Oh... I just thought that was a quaint English street accent, soon to be corrected by a snooty English bachelor, and followed by some rousing singing and dancing.
What would have happened, had it reached an unexpected obstacle, is that it would have just stopped and waited patiently until humans intervened. That's the smart thing for software to do, rather than try to get clever about a situation it doesn't understand. The issue would be reported, the manufacture would pore over the sensor and log data, the software or maps would be updated, and that particular issue would likely be avoided in the future.
I think most people would acknowledge that humans are much better at improvising and problem-solving in unexpected situations than computers are. Computers are much better, however, in performing repetitive, pre-programmed tasks, or reacting to navigational events extremely quickly.
I've never figured out that "40 year old analog technology" angle. My Mark-1 ears are also 40 year old analogy technology, so I think they match up just fine.
That's actually how my interprocess communication library handles the details underneath the interface (the Windows FileMapping API). And yep, it's extremely fast.
I haven't tried managed C++, but it sounds interesting (if I hadn't already done all the work).
I'm using modern C++ everywhere, but I still haven't found the transition to a C-style interface too onerous in most cases. As you surmised, the most awkward sections tend to be when dealing with C++ types passed around at the interface level. My typical approach is to transform the data into a structure that works in the managed code. For instance, my engine works natively with UTF-8 strings, so I need to convert between UTF-8 and 16 for each string passed. Sort of a pain, yes, but it's just a quick conversion function, and I haven't found the performance to be that bad in my case.
Part of the complexity of my system is that I not only use managed to native code interop, but I also have to transmit a lot of data across a process boundary as well. The native part of the editor window that shows the rendered game view is isolated in a separate process, so that any problems or crashes in it don't bring down or hang the main editor. As such, the nature of this system lends itself to simpler C-style interfaces anyhow, since I have to serialize everything into primitive data streams and re-interpret all those commands and data in the other process. That means the data has to be transformed into a serializable format at least once anyhow.
HDDs still make sense for local bulk storage requirements, where SSDs would not only be much more expensive by comparison, their speed would be largely wasted, since most of the time their job is just to store large amounts of data passively. It's pretty common for small businesses or specialist hobbyists to make use of a NAS with lots of local bulk storage configured in a RAID, then use a cloud-based service as backup. That's how my own home-based business is set up, in fact. Since I need lots of disk space, but don't typically work directly off the NAS, price per GB is the most critical factor.
I agree that HDDs will eventually be completely replaced, but that's only when the price per GB and capacity of SSDs gets reasonably close to HDDs. The gap is closing, but it's still nowhere near at the moment.
I had to explain the same thing to my mom, who was concerned about how we were "handing over control of the internet". I told her that this was sort of like handing control over the entity that assigns unique telephone numbers to people, but it doesn't control the phone lines themselves.
Besides which, the internet is somewhat resistant to change of *any* sort, as evidenced by the extremely slow adoption of things like IPv6 and DNSSEC, both of which would be very useful, but simple mass inertial keeps adoption rates down. So, any radical changes by these bodies would likely just be ignored not only for ideological reasons, but for practical ones as well.
I also do this all the time between my C# (tools) code and C++ (game engine) code, and I've never found it constraining, although it's certainly tedious to recreate all the APIs in C. Creating a C-style interface for just about any C++ objects is reasonably straightforward if you break it down into handle (address of object) + method. As for exceptions, game development generally doesn't use them (in native code), but yes, that would require each native method to wrap the API function in a try-catch block, then pass along errors as a C-style error code.
If performance is an issue, then it may be a sign that your interop API may be a bit too fine grained, and needs a mechanism to batch calls a bit, perhaps by moving a bit of logic down into native code so you can make fewer, more meaningful interop calls. Performance work is, unfortunately, often diametrically opposed to clean design.
Yeah, at the time, the thought of needing more than four billion internet addresses probably seemed a bit ludicrous when it was still mostly just government and university mainframes connecting. That number must have seemed like a nearly never-ending well, especially seeing how generously it was initially carved up into massive blocks. Some of the earliest corporations and universities to receive allocations still have a relatively ridiculous number of Class A blocks allocated addresses (16+ million).
We'd probably still have plenty of addresses were those initial blocks handed out a bit more judiciously, but again, part of that was done, if I understand correctly, for simplicity of routing. It's easy to criticize with the hindsight of today's hardware and needs, but those early computers were incredibly restrained on memory and CPU speeds. Even a 64-bit address would have been seen as doubling memory requirements of routing hardware for no good reason.
Agreed. A lot of us envisioned these sorts of "intelligent agents" many years ago, but I think we always envisioned they'd be local agents, or under our control somehow. Probably a bit naive, I guess.
Even so, the problem with using a local agent is that it would be difficult to automatically synchronize this information across all your devices. That's the benefit of a cloud-based service. The downside? Someone else has complete access to all the most intimate details of your life. And what privacy guarantees do we have? A "we promise" statement from the company that they won't abuse that power. Nevermind that all that data is a virtual goldmine to advertising agencies... I'm sure we can trust them.
I think that this could be done locally (and share an encrypted database in a service like Dropbox, etc), but there's no incentive for a corporation NOT to keep all that personal data in their own cloud. They'd have to work harder to cut out their own ecosystem and protect the user's privacy. And frankly, it would be harder for the end-user to use, and less convenient than using Cortana, Siri, Alexa, or Google's bots. It would be tough for such a system to gain widespread adoption. And we've seen, via Linux as a desktop OS, that simply being free and open is NOT enough to drive mass adoption.
Aaaaand... like an idiot, I failed to notice that this information is right there in the summary. How often does one read TFA and fail to read the summary? That has to count for something, right?