Response to the Steam Controller varies a lot. I have a hypothesis on it.
First, why Linux and SteamOS? Windows 8 isn't such a disaster for games as the Windows App Store (if successful) could be a disaster for Steam. Valve wants independence and revenue as much as any other company.
The controller has a stated purpose: "[bridging] the gap from the desk to the living room without compromises." I think there's another one.
On some site (sorry, forgot which), I saw a comment claiming that there is no battle for the living room but rather that the battle is in mobile. I haven't looked up market sizes, but Sony, Microsoft, Apple, and Google all have at least some belief in the value of the living room.
However, mobile is an important space. We see Microsoft betting their reputation on this.
What can Valve do here? Android is as open as Steam Machines will likely be. Do they dodge Android because their focus is serious gaming? Yes and no, I think.
They care about the serious gaming segment, but they've also already lost on iOS and Android. Apple and Google already have app stores. Steam can't compete there. That's what they want to avoid with Windows. They want Steam to be its own power.
This is where the screen on the Steam Controller comes in. I don't think on its own it will be much more exciting than the Wii U GamePad's screen is. It competes with the main display. However, if the Steam Controller is hackable (stated goal by Valve), surely some people will make games just for the controller. And if the controller is a success (open question), that might become meaningful.
If the Steam Controller succeeds, it provides a rich IO platform that might possibly become a successful mobile platform of its own.
Yes, this is a crazy hypothesis, but it allows an avenue for Valve to move in this direction without making it a major immediate focus. Having future options might not hurt.
Wednesday, October 2, 2013
Thursday, September 26, 2013
Nostalgia
Pandora playing "Rhythm in the Pews" by Ray Lynch on "Deep Breakfast" just pulled my heartstrings out.
No particular story, but it totally dropped me right into the middle of high school.
So many miles and years from there.
No particular story, but it totally dropped me right into the middle of high school.
So many miles and years from there.
Monday, August 26, 2013
Palantir Eclipse TypeScript
Among other languages, I've toyed some with TypeScript over the past half year or so. Lack of good IDE for my use case (Eclipse, not VS) was lacking. But now a company called Palantir has been working on a decent TypeScript plug-in for Eclipse.
Hurrah!
I think I'm more in line with TypeScript than with Dart, and last time I tried the Dart editor (in the past month or so), it kept using high CPU all the time (maybe related to issues like this, not sure), and it was slow and flaky for its inference and code editing support. If JS really has speed limits that Dart can break, maybe I'd change my mind. Or if the Dart editor actually got any good. Don't know. For now, though, I like TypeScript better. It seems more "the right thing" to me.
Now if only Microsoft would add operator overloading to TypeScript and if someone would implement a TS to C++ compiler with full instant support for header parsing (pipe dream, maybe), I might really be able to make TypeScript my real go-to language. I'd prefer different, but it might be good enough.
As an aside, I'd really like this TS clone problem to go away, too. Even if it's a GnuTLS issue, it's only hit me at CodePlex so far as I know.
Hurrah!
I think I'm more in line with TypeScript than with Dart, and last time I tried the Dart editor (in the past month or so), it kept using high CPU all the time (maybe related to issues like this, not sure), and it was slow and flaky for its inference and code editing support. If JS really has speed limits that Dart can break, maybe I'd change my mind. Or if the Dart editor actually got any good. Don't know. For now, though, I like TypeScript better. It seems more "the right thing" to me.
Now if only Microsoft would add operator overloading to TypeScript and if someone would implement a TS to C++ compiler with full instant support for header parsing (pipe dream, maybe), I might really be able to make TypeScript my real go-to language. I'd prefer different, but it might be good enough.
As an aside, I'd really like this TS clone problem to go away, too. Even if it's a GnuTLS issue, it's only hit me at CodePlex so far as I know.
Tuesday, August 20, 2013
Mirror neurons and reusable APIs
One topic in neuroscience that gets a lot of attention in recent years is the "mirror neuron" thing (see here, here, or here). Decades ago, Rizzolatti et al. discovered that certain neurons would fire whether the subject was performing a relevant task or just watching someone else perform the same task.
Lots of fun discussion exists on the meaning of this.
My quick take is that it at least suggests modularity in the brain. If I developed a well-factored software API for handling any task of any sort (really, speaking of any half-serious software here), I would build reusable functions to support various aspects of the system. That's just expected, right?
Well, say I have some code paths using helper functions that actually do visible IO (say to a database or a web page or a robot arm or ...), the same helper functions would also likely get used in other contexts.
Drop a trace of some sort in said helper function, and you'd see it being used whether for visibly active things or not.
Mechanics and various use cases aside, that seems clear to me what is happening in mirror neurons. Much of the research exists around "what specific use case would these reusable functions have" and that's definitely interesting, but to me, the core is that reusable modularity is going on.
In a bit more searching, I also just learned that relevant term sometimes used in neuroscience is subserve (or subserving).
Lots of fun discussion exists on the meaning of this.
My quick take is that it at least suggests modularity in the brain. If I developed a well-factored software API for handling any task of any sort (really, speaking of any half-serious software here), I would build reusable functions to support various aspects of the system. That's just expected, right?
Well, say I have some code paths using helper functions that actually do visible IO (say to a database or a web page or a robot arm or ...), the same helper functions would also likely get used in other contexts.
Drop a trace of some sort in said helper function, and you'd see it being used whether for visibly active things or not.
Mechanics and various use cases aside, that seems clear to me what is happening in mirror neurons. Much of the research exists around "what specific use case would these reusable functions have" and that's definitely interesting, but to me, the core is that reusable modularity is going on.
In a bit more searching, I also just learned that relevant term sometimes used in neuroscience is subserve (or subserving).
Friday, April 19, 2013
Dart: Static or Dynamic?
Dart Language folks just announced plans to make reflection more statically analyzable. Full-core reflection makes optimization hard. Yes, I believe that.
So, what does it mean to be "dynamic and proud of it"? To "take full advantage of its dynamic typing" means simple static analysis isn't so easy. Are there are specifically indicated advantages to dynamic typing that they actually claim anywhere?
And the current Dart VM doesn't get anywhere near Java for performance, despite claims that type checks don't help. Maybe they just need more time to optimize the VM? And as for producing tight JS, I suspect enforced type checks would avoid the need to whole program analysis.
Is Dart trying to get the worst of both worlds? More difficult optimization? Slower performance? No dynamic tricks? An unenforced static nominal type system with runtime structural typing?
I only casually observe Dart, so maybe I'm missing something, but I'm not sure they know their target.
On the other hand, I had been dismissing Microsoft's TypeScript for a while, but tried it out this past week. No Eclipse love, but TypeScript actually does a good job of providing the JS we already know but with a static analysis system (and no Dart-like fear of that "inference" word) that's adapted to existing JS usage patterns. It's pretty good.
So, what does it mean to be "dynamic and proud of it"? To "take full advantage of its dynamic typing" means simple static analysis isn't so easy. Are there are specifically indicated advantages to dynamic typing that they actually claim anywhere?
And the current Dart VM doesn't get anywhere near Java for performance, despite claims that type checks don't help. Maybe they just need more time to optimize the VM? And as for producing tight JS, I suspect enforced type checks would avoid the need to whole program analysis.
Is Dart trying to get the worst of both worlds? More difficult optimization? Slower performance? No dynamic tricks? An unenforced static nominal type system with runtime structural typing?
I only casually observe Dart, so maybe I'm missing something, but I'm not sure they know their target.
On the other hand, I had been dismissing Microsoft's TypeScript for a while, but tried it out this past week. No Eclipse love, but TypeScript actually does a good job of providing the JS we already know but with a static analysis system (and no Dart-like fear of that "inference" word) that's adapted to existing JS usage patterns. It's pretty good.
Wednesday, January 23, 2013
Rust compiler speed
I haven't tried out Rust for several months, but it's one of the languages I watch as something I might use someday. A recent discussion of compiler speed as a lower priority worries me somewhat, though. That's one of the priorities I feel Go gets right. Go gets other things wrong in my opinion, though. Hrmm.
Compiler speed on Rust is somewhat blamed on Hindley-Milner-ish type inference, by the way. They feel that's important.
Compiler speed on Rust is somewhat blamed on Hindley-Milner-ish type inference, by the way. They feel that's important.
Tuesday, December 4, 2012
Defeating Gnome Evolution
Once upon a time, I apparently imported my Google Calendar info into Evolution, thinking the integration would be a good idea. It drives me crazy. The web interface is good enough.
Sad thing is, Evolution wouldn't let me delete the calendar. I searched for solutions, and nothing worked.
What did work was this (and maybe some of this is overkill, so don't sue me if you lose something you want):
Again, this isn't a scientific report. Just vague notes on what I did. Don't blame me for anything.
Sad thing is, Evolution wouldn't let me delete the calendar. I searched for solutions, and nothing worked.
What did work was this (and maybe some of this is overkill, so don't sue me if you lose something you want):
- Kill all evolution processes. I needed sudo for the calendar one, and that's probably the one that really mattered.
- Kill the goa (Gnome Online Accounts) process.
- Watch out, because evolution processes like to start back up on their own.
- Delete .config/evolution (although maybe just the related sources files would have worked).
- Delete .config/goa-1.0 (and again, maybe could have been more selective).
- Delete .cache/evolution (and again, maybe could have been more selective).
After all that, if I logged out and back in or otherwise let Evolution restart, it no longer tried to access my Google data.
Anyway, it felt like virus hunting I've done in the past on friends' computers. Things just kept coming back. Is any "robust" software like a virus? At least to me in this case, Evolution was serious malware.
Again, this isn't a scientific report. Just vague notes on what I did. Don't blame me for anything.
Subscribe to:
Posts (Atom)