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