Wolfram discovers OOP

Now, I'm probably being abusive here, but I think Wolfram is overblowing his value in his Wolfram Language announcement. When he says this:

In most languages there’s a sharp distinction between programs, and data, and the output of programs. Not so in the Wolfram Language. It’s all completely fluid. Data becomes algorithmic. Algorithms become data.

... I think this:

In contrast, the object-oriented approach encourages the programmer to place data where it is not directly accessible by the rest of the program. Instead, the data is accessed by calling specially written functions, commonly called methods, which are bundled in with the data.

... or perhaps even things like OpenDoc. He also sounds very Smalltalkish. I don't think he's talking Lisp-like code as data, but maybe he means that, too.

Saying "That there’s a completely general and uniform way to represent things" is also like saying "if S is a subtype of T, then objects of type T in a program may be replaced with objects of type S without altering any of the desirable properties of that program" (Liskov substitution principle).

Would Wolfram be the type to reinvent the wheel without full formal training in a subject matter? Um, yes.

I do love Wolfram Alpha, though.

Having algorithms is great, and for general web user accessibility, flexible language is nice, but when I want to be serious, I like a real programming language. And microkernel at that. Contrast Wolfram's statement that his "concept from the very beginning has been to create a single tightly integrated system in which as much as possible is included right in the language itself."

Hmm.

In more interesting news, Ceylon 1.0 was released a few days ago.

Steam Controller and app stores

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.

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.

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.

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).

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.

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.