923 karma · joined August 13, 2011
But I still hope that the technology gets researched and built out as far as it can go, because _something_ is necessary for virtual interfaces to work.
Oracle's reputation was of abysmal pay for senior employees, for decades. I'm willing to bet that economically they should have moved a long time ago, but Larry Ellison's pride kept them in the Bay Area. He designed the campus buildings to look like database icons, that's not something you give up easily.
That said, you're right in that one may have to make some changes to code to get around some new problems. The problem with FFI/CPU-heavy functions is that they prevent _other_ fibers from being scheduled while they run.
If it becomes possible to implement work-stealing, then that would mitigate the problem. It would also be solvable by sprinkling "yield to scheduler" calls throughout such functions. Annoying and not always possible, but, since in these cases the signature would not change, technically not coloring.
This is huge. They solved the function-coloring problem by deciding that all functions are now potentially async. It makes it more likely that the ecosystem as a whole actually becomes async-compatible. I wish Python had taken this approach, though I understand why they didn't.
It probably will eventually be a successful thing, probably slowly and incrementally, but I think that the rush to be first to market caused all parties involved to make some mistakes that prevented the wild success they were envisioning.
- They should have been even more experimental. Bootstrapping a market is difficult. The way it goes is that the audience is zero at the start, so no sensible publisher or developer would risk their money over the years it takes to build a game, so the platform creator has to fund them 100%. But that also means that the platform creator gets to control the games and how they're made. I got the sense that the VR platform owners were overly controlling. I was involved with several different headset makers and they were pretty specific about how the input devices had to be used, limitations on the permissible content, and what kinds of games they were looking for. That makes sense for a mature platform where you know what a killer app looks like, but I think they needed much more experimentation for VR. When we first started building for VR, our team strongly believed that it would be the most fun to make games that focused on small-scale, close-up experiences, basically fitting everything on a tabletop. But we were steered away from such ideas, in part due to platform pressure. I guess they felt that big, splashy, open experiences were going to dominate (or would at least make good screenshots for marketing), but they were wrong. Long distance scenes aren't actually that cool in VR because the stereoscopic difference goes to zero; it becomes no different from looking at a monitor. Maybe small-scale stuff wouldn't have worked out -- the lack of vergence cues may cause additional eyestrain -- but it still seems like a big unexplored area of potential.
- Fragmentation is a huge problem. Even within one single headset model, developers cannot assume that players have more than a seated chair's worth of space. If you make a game that accepts that limit, it feels like you're "not really doing VR" and that pisses off funders. So you try and awkwardly have some sort of "progressive enhancement" that makes the game more fun when moving around the room, but still playable when stationary. You really have to build the entire game around such a compromise, so most such games felt very demo-y (e.g. Robo Recall, Job Simulator). Plus all the options for the inputs -- remember how the Rift shipped with an xbox controller? Building a game that can use either xbox or 3DOF or 6DOF controller is madness; the paradigms are totally different. So you're pretty much limited to building a lowest-common-denominator system, which sucks. I think Oculus is trying to address this now, by focusing on standalone headsets, but that saddles them with additional technical challenges so it'll be a few years before that can succeed.
- Inputs are everything for VR, and I don't think people realize how late in the game they actually were. When Oculus and Vive announced, the problem of having accurate-enough handheld controllers was not known to be solvable. Valve's "room demo" had inside-out head tracking that looked at barcodes plastered on the walls, clearly a temporary hack. Good game development takes years; not having a reliable input paradigm to count on _severely_ impacted developer productivity. That said, vehicular games like Elite which can treat the VR headset as a more immersive display were and continue to be some of the high points of the VR experience. I think that they thought that more genres of games would behave like that, but, no.
- I think it was a mistake on Oculus's part to have different levels of buy-in for their platform. It would have worked better if there was one package that everyone bought, even if it was expensive. Maybe the thought that they could have a cheap version for the masses, and people who wanted a better experience could spend more. But it isn't the case that getting the fancier VR package improves the visuals without affecting the gameplay; the different controller types and increased precision substantially changed the types of games you were able to play, exacerbating the fragmentation problem.
- The technical road to having high resolution displays and low-latency rendering was too long. It may be there now, after 5 years of concerted effort, but it wasn't in 2016. If the renderer can't keep up, it's super noticeable in VR. The analogy is capacitive touchscreens. Until they were _absolutely nailed_, they were worse than no touchscreen at all.
Game platforms fail to take off all the time, this was just one of the more well-funded and public ones. Remember the Ouya? Google's various game platforms preceding Stadia? Stadia itself? Failure is the norm; what might eventually turn this around is the very strong dedication some people have to the idea.
I guess it's a layered security situation.
I agree that in practice maintenance has been pretty bad for C++ programs, but I think I understand the kind of reasoning that led so many organizations to pick C++, even if I don't agree with it. It was not about ergonomics or productivity, but about control. The language grants an unprecedented level of power to a small group of elite programmers inside every organization, who author the standard library and headers that all the other programmers use. They're building the smart pointers, the memory allocators, the IO libraries, and the build systems. It's imperative (to them) that their good decisions don't get snowed under the mountain of application code that the more mediocre programmers are going to be producing by the truckload. So it's important to have powerful encapsulation, compile-time checks, and metaprogramming capabilities. Doesn't matter how safe by default or how slow it all is, because the elite add guarantees themselves through the abstractions they write, and don't have to compile a full application very much, if ever.
One property I anecdotally observed about it is that it is a little sensitive to the values you choose for its seed. Too many zero bits or making two generators with nearly-identical seeds would create visible correlation in the outputs. It worked much better if all values were hashed before using them for seeding.
[1] https://www.businessinsider.com/fedex-saved-from-bankruptcy-...
> Results indicate that corrections frequently fail to reduce misperceptions among the targeted ideological group. We also document several instances of a “backfire effect” in which corrections actually increase misperceptions among the group in question
- Is it petroleum-based? Looks like the answer is no. [1]
- What's the durability? PVA seems to be very water-soluble [2]
- How's the scratch resistance? I wasn't able to find a source.
[1] https://en.wikipedia.org/wiki/Polyvinyl_alcohol
[2] https://www.cfsanappsexternal.fda.gov/scripts/fdcc/?set=GRAS...
The developing narrative seems to be that self-driving was a longshot that could have paid off hugely, had it worked out, but it's been plagued with problems and it just seems very unlikely to pay off now. But still not zero, since no one else has shipped anything.
Investors probably valued it like (0.7% chance of success * 1 trillion upside = 7 billion).
I think the broadest interpretation is that autonomous driving was one of a few irons Uber has had in the fire to achieve profitability. The other irons include Uber Eats, Jump, and lately, grocery delivery. The miracle hasn't happened yet!
There is survivorship bias, but it's kinda all happening within the one designer.
In actual water crises, such as the one in California, limiting and controlling consumption is the response. Obviously, it's always better to come up with an alternative before you reach the crisis. But once you've gotten to the crisis, you're already exhausted all other options and have to be realistic.