[sillysaurus3]

My point? Before I get to my point, how about a rant: It mystifies me how nobody sees the obvious advantages of in-browser games, both for development and deployment. It should be obvious to anyone in the field, because the current method of developing and deploying games completely sucks. Do you honestly think that in 100 years, people are going to be deploying games through Steam, or worrying about cross-platform OS support? If so, you may want to rethink that. If not, then why wait 100 years? There's no reason to put up with the current limitations.

Except, oh wait, the only reason we do have to put up with the current limitations is because we're beholden to the browser manufacturers to implement support into their browsers for features that gamedevs will use. Like, say, having a >5MB area to store art assets. I'm pretty sure that's the only real reason we're not seeing in-browser games. Not because JS sucks. Not because WebGL sucks. But because even if you actually do make a game using a browser as the platform, there's nowhere to store the damn thing!

So, back to that "point" you were asking about. What was my point with my oh-so-pointed "Why does Haskell have a REPL but Go doesn't" question? Well, it was a question. The thing you ask when you want to learn something. In this case, I had no idea why Go (a statically typed language) doesn't have a REPL, when Haskell (a statically typed language) apparently does. In fact, I had no idea Haskell had a REPL at all! I had no idea that it was even possible for a statically typed language to have a REPL. Those ideas seem as separate as oil and vinegar. So it's pretty damn cool to hear that it is in fact possible and practical to have a REPL for statically typed languages, and now there's a mystery: Since REPLs are such a productivity boon, why don't all statically typed languages have them? I'm not at all afraid to admit ignorance; I wear it on my sleeve. It's the only way to learn. But I guess we're so far gone, here, that people misunderstand a simple question meant to learn something as some kind of snide, rhetorical, or coy remark.

So, yes, sure. Go sucks. JS sucks. WebGL sucks. Steam is amazing. The only real way to develop a game is with C++, deployed as a native OS binary, or with someone else's engine, also deployed as a native OS binary. Keep the status quo. Pretty boring, isn't it?

[lmm]

Ok, my apologies. I genuinely thought you were trying to make some kind of point. Haskell has a REPL, Scala has a REPL, OCaml has a REPL, F# has a REPL; it's not at all unusual for a statically typed language to have a REPL.

(If I had to guess why Java doesn't have one I'd assume its emphasis on OO and everything-is-a-class; expressions in a REPL are almost inherently not contained in a class. For C/C++ I'd guess the emphasis on manual memory management and programmer-visible memory layout don't play nicely with a REPL. And for go I'd guess because it doesn't like including features that weren't in Algol '58. I don't think that's the real reason, but I am literally incapable of understanding what people like about go. Those are just guesses though)

> It should be obvious to anyone in the field, because the current method of developing and deploying games completely sucks. Do you honestly think that in 100 years, people are going to be deploying games through Steam, or worrying about cross-platform OS support? If so, you may want to rethink that. If not, then why wait 100 years? You can invent the future today. There's no reason to put up with the current limitations.

To me the browser just seems like an extra layer of junk, particularly when you're talking about things like WebGL where the API talks more-or-less directly to the graphics card. So I certainly hope the future looks more like steam - a library interface where I can run any program I want, automatically updated, with my saved data automatically kept in sync. Once you have a system that looks like that, what's the advantage of the browser? Put another way, if we're writing a game runtime, why would we include a document layout engine, an extremely complex styling system, and all the other stuff a browser comes with? I certainly hope the future looks more like Steam than like the browser.

I agree that developers shouldn't have to worry about cross-platform. I think it's a damning indictment of our industry that the best way to get a cross-platform runtime environment for your program is to bodge it into a scripting language that was written in three days to bolt on to a remote document viewer. I'm hoping that things like MonoTouch mean we're getting closer to a cross-platform runtime that provides a better platform for general-purpose applications and games.

"Boring" is what platforms should be; stable, reliable, almost invisible unless you're looking at them. I agree that there are better things than C++, and I do what I can to contribute to them. But I really hope the browser isn't the best we can do.

[sillysaurus3]

If a browser is an extra layer of junk, then surely a bunch of the features that come with an OS are unnecessary junk too. Printer drivers, for example. But of course, printer drivers don't impede the ability to make games in any way. The fact that platforms have features which are useful for other purposes is unrelated to whether a platform can be useful for a specific purpose, like making games.

There's nothing that Steam can do which can't also be done in a browser. Except, of course, store more than 5 MB of assets.

Why not use Steam? Because Gabe is going to die someday, and there's no reason to think that his successor will inherit his good judgement. Locking yourself into a monoculture isn't a good idea when your whole business can be smashed by one poor decision by the company pushing that monoculture. It's the same reason you don't see any companies built solely on Facebook or Twitter. (Apple is a notable exception, but companies can still live or die based on whether Apple feels like admitting you into their appstore.) Yes, Steam is pretty awesome right now, but arguing against exploring other alternatives is arguing against progress of any kind.

Your objections seem to boil down to "a browser isn't meant for games." Well, nothing short of a gaming console is truly meant for games. But a browser can be used for games, if only the manufacturers would provide a single necessary tool: a place to put them. That is the sum total of my argument, and it mystifies me why so many people are not only against this idea, but somehow offended that a browser might be repurposed for anything other than viewing lines of text.

[lmm]

> If a browser is an extra layer of junk, then surely a bunch of the features that come with an OS are unnecessary junk too. Printer drivers, for example. But of course, printer drivers don't impede the ability to make games in any way. The fact that platforms have features which are useful for other purposes is unrelated to whether a platform can be useful for a specific purpose, like making games.

But if you don't want to use them, printer drivers don't get in the way. Even if I'm laying out my screen by hand, I still have to worry about what the browser layout engine will do if the user resizes the window. If I want to capture keyboard input, or even just make API calls, I have to jump through hoops to convince the browser I'm not a malicious remote document. And whatever I'm writing, I have to transpile it into javascript, which is a pain for debugging.

> Why not use Steam? Because Gabe is going to die someday, and there's no reason to think that his successor will inherit his good judgement. Locking yourself into a monoculture isn't a good idea when your whole business can be smashed by one poor decision by the company pushing that monoculture. It's the same reason you don't see any companies built solely on Facebook or Twitter. (Apple is a notable exception, but companies can still live or die based on whether Apple feels like admitting you into their appstore.) Yes, Steam is pretty awesome right now, but arguing against exploring other alternatives is arguing against progress of any kind.

Are you that much safer on the browser? You'll write games that work for one, maybe two rendering engines - one of them made by google, the other made by an organization that gets most of its funding from google. The web's standards might theoretically be open, but they're so enormous and complex; writing your own browser from scratch (to the standard that modern html games require) is beyond the resources of all but the biggest organizations.

I'd certainly favour an open standard for a steam-like games runtime. Which would be a lot simpler than the browser standards, which would make competing implementations much more practical.

> Your objections seem to boil down to "a browser isn't meant for games." Well, nothing short of a gaming console is truly meant for games. But a browser can be used for games, if only the manufacturers would provide a single necessary tool: a place to put them. That is the sum total of my argument, and it mystifies me why so many people are not only against this idea, but somehow offended that a browser might be repurposed for anything other than viewing lines of text.

I am offended, because I have a sense of engineering aesthetics, and bodging everything into the browser is ugly. And from a practical point of view, I fear a future where the only programming jobs require javascript, because having to write javascript makes me very sad.

[the_af]

> Why not use Steam? Because Gabe is going to die someday, and there's no reason to think that his successor will inherit his good judgement. Locking yourself into a monoculture isn't a good idea when your whole business can be smashed by one poor decision by the company pushing that monoculture.

I fully agree with your opinion on this. I also can envision a future where AAA games can run fine on the browser, which would act like a universal platform. Not sure if this will ever come to pass, but it is technically feasible. I just don't like javascript :)

[pjmlp]

There are REPL like implementations for Java, like Eclipse's scratchpad.

For C and C++ you can use CINT, for example.

Two nice REPL experiences for strong type languages similar to Interlisp-D and Smalltalk, were the Mesa/Cedar environment and Oberon, which was inspired by Wirth's experience with Cedar.

[cwyers]

> Do you honestly think that in 100 years, people are going to be deploying games through Steam, or worrying about cross-platform OS support? If so, you may want to rethink that. If not, then why wait 100 years?

In 100 years most of my plans revolve around being dead. The best tools for delivering AAA-quality games right NOW are native binaries on Windows and dedicated gaming consoles.

And yes, JavaScript and WebGL "suck" for AAA gaming development. JavaScript is a dynamically-typed, garbage collected language that can't deliver the performance of well-written C/C++ code, and WebGL is a subset of OpenGL, which by definition makes it less powerful than the full OpenGL that's available. And on Windows, the biggest platform for AAA games that also runs a full web browser, WebGL is just a wrapper that sits on top of DirectX, which means an additional performance hit.

[the_af]

I support your overall idea that there must be some kind of universal platform such as the browser. And that Steam and similar services -- as much as I love them now -- are not the long term answer.

But javascript? Is there any reason why we can't have a better language on the browser? Languages and tools do matter, after all.