[sillysaurus3]

Why wouldn't you want to produce a AAA-quality game with javascript and WebGL? It should be the default, not some crazy thing.

The best argument against javascript + WebGL is "javascript is bad." But the disadvantages of JS are sometimes strengths. The lack of static typing, for example, allows a REPL. It's true that with an average gamedev team, you'll get below average results. But with an above-average team, powerful languages tend to translate into stellar results.

Oh well, I guess I'll wait a few more years for browser vendors to implement some kind of concept of a webapp installation.

[the_af]

> The lack of static typing, for example, allows a REPL

Uh? Languages with static typing can have REPLs. See: Scala, Haskell and more. I don't think that is what makes JS an option for game development, but rather its ubiquity in browsers. If you remove that, I don't see why you would choose it for serious development.

[sillysaurus3]

Why does Haskell have a REPL but not Go?

[judk]

Haskell has an interpreter as well as a compiler. No one cares enough about making one for Go.

I used a C interpreter a decade ago.

[pkroll]

A quick Googling would have shown two REPLs for Go, though they're old and haven't been updated in a long time. I'm guessing the Go playground and "go run file.go" compiling and running so quickly, make it not a real concern.

[the_af]

I don't know why Go doesn't have a REPL, I'm not familiar with the language. My point is that having static typing does not preclude a nice REPL.

[lmm]

Because Go sucks? What point are you trying to get at here?

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

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

[dragonwriter]

> Why does Haskell have a REPL but not Go?

Because no one's bothered to create a REPL for Go.

[shard972]

> Why wouldn't you want to produce a AAA-quality game with javascript and WebGL? It should be the default, not some crazy thing.

Performance. Show me some like gears of war running in a browser and then I will be convinced.

> The best argument against javascript + WebGL is "javascript is bad."

That is the worse attempt to portray the other side's argument I have seen a while.

> The lack of static typing, for example, allows a REPL.

You can also just have a console implemented, like most AAA games. They are also built into engines like Source.

> It's true that with an average gamedev team, you'll get below average results. But with an above-average team, powerful languages tend to translate into stellar results.

I don't understand how javascript would allow someone like John Carmack to make anything new, I write Javascript every day but when it comes to games I much prefer something like c#.

[sillysaurus3]

Look up Unreal engine in the browser. It runs quite nicely.

You're right that I did a poor job explaining why people are against JS for gamedev. Sorry about that.

[squeaky-clean]

The only game demo I can currently find for UE4 in the browser is Flappy Chicken (I know they had some up earlier, but they seem to be taken down). Not really a compelling AAA demo. And their 3D games still only run about half as fast as a native C++ engine. That's very impressive, but you won't be putting out AAA games with a 50% performance hit.

And even then, unreal engine in the browser doesn't run Javascript written by developers. It compiles the C++ code into asm.js. Huge difference. Unless you can code asm.js by hand, you won't be able to do that. Here's a sample of the Flappy Chicken UE4Game-HTML5-Shipping.js file, because the code is just too long and ugly to paste.[0] Definitely not 'JS for gamedev.'

[0] http://i.imgur.com/O3w61XI.png

[sillysaurus3]

This has been up for three hours, and it's telling that no one has replied to it with a rebuttal.