Anything that is wanted by the community will likely find its way in.
Unless the community gets bored and moves on to languages like Scala, Clojure, Ruby, etc, which already have what they want.
You see, the Java world runs like a Democracy. People don't like Swing and eventually there's SWT.
And this is different than anything except Delphi, how?
In the MS world, you're just plain stuck.
...until you realize there's Mono.
Also, half the things you mentioned (Swing, SWT, JSP, Struts, EJB, Hibernate...) are just frameworks. Just because.NET comes from Microsoft and ASP comes from Microsoft doesn't mean you can't write web services in.NET without ASP -- or without IIS, for that matter.
But again -- anonymous fucking functions. Javascript has it. Lisp has it. Ruby has it. Perl has it. C# has it. Smalltalk has it. Hell, even C has it -- this is not exactly a new idea.
Java can sort of kludge it together with anonymous classes. And it looks absolutely nothing like it does in C# -- even Javascript manages to make it look better than Java.
Seriously, show me the Java equivalent to:
var foo = function() { // do some stuff } setInterval(foo, 1000);
Or maybe:
(1..100).select(&:odd?).each do |num| # do something to only odd numbers end
Contrived examples? Sure. But I'm sorry, your "language that looks 99% the same as Java" actually looks nothing like Java, unless you claim JavaScript "looks 99% the same as Java", in which case:
Your "looks like" is only skin-deep -- they are about as different as two imperative languages can be.
The iPod was a 20-year-later elaboration of the Sony Walkman.
*facepalm*
You know, there used to be this thing called an mp3 player, and later a portable music player. They're still around, but as soon as the iPod got popular, these other things like the Rio and the Nomad were suddenly seen as "iPod clones", even when they predated the iPod.
The innovation of the iPod was making it simple enough for everyone to use, not inventing the thing itself. The innovation of the Walkman was making it portable in the first place.
When Java adds something as simple as anonymous functions, I'll concede your point.
And no, I'm not an MS fan. I like Ruby. But I think you're crazy if you don't at least see how a lambda closure -- especially a dirt simple lambda closure, in a tiny bit of syntax instead of a class and a half -- is not at all like Java.
So even if you're serving a page over HTTPS, a malicious user of your system might have created the elements.
Still doesn't mean I'm planning to run eval on any string that I didn't create, or that a script I created didn't create.
And this XHR-then-eval technique is something I've used in real apps. I doubt I'd give it up without a replacement.
Most lag in online games isn't as sensitive to bandwidth as the kind of lag you get from streaming the textures.
True -- it is, however, sensitive to latency (which can be sensitive to bandwidth), as well as local RAM, CPU, disk (sometimes), and video capabilities.
A 3 Mbps link is about as fast as the 2x CD-ROM drive in an original PlayStation. So I guess if people come in with expectations of PS1 quality, which is still an upgrade from the roughly GBA quality of DHTML, 2D canvas, or SWF, they might accept it.
Right. Missing a couple of points, though:
Many people have better than a 3 mbit link. Games that can scale will look better on a faster connection.
Many times better GPU, CPU, and RAM than a PS1.
You are deliberately ignoring local disk cache.
"Seek time" would be significantly less than a PS1. A PS1 optimization (still used for optical disks, particularly Blu-Ray) would be to duplicate content all over the disk, so that you can read a level in a single shot, with no seeks. On the web, that content would be either already cached, or no slower to download than anything else.
It's been tried. Remember how long it took PS1 games to boot to the menu?
You mean, after all the logos that have to go into games? Yeah, I guess interstitials would cause that, too.
But no, I don't think we've seen anyone try to reduce boot time of a game to where it can be quite that kind of impulse thing (the way YouTube is).
People will see loading every time they play, just like on the PlayStation, because most people aren't going to let a single web site cache hundreds of megabytes.
...why not? I mean, if the alternative is to actually download hundreds of megabytes and store it permanently, why wouldn't I just crank up my browser's cache to use, oh, 10, 20, 50 gigs? I've got the space, and so do most people -- the way that space would otherwise be used is with games, massive amounts of audiovisual content, or virtual machines.
It's possible there are uses I'm not thinking of, but really, even netbooks come with at least some 8 gigs, laptops tend to be around 300 gigs, and it's hard to buy a hard drive with less than 80 gigs anymore.
Keep in mind, it's just browser caching -- which means it also benefits from a caching proxy (Squid, say), and it means it's not the site doing anything, it's the browser caching. Every browser I've tested this on can cache XHRs as easily as anything else.
will be running on JS which isn't comparable in speed to binary or ASM programs.
But it is comparable to Python, and people have written interesting GL games in Python.
It doesn't have to be as fast, it just has to be fast enough.
Google Docs is slower than MS Office or even Open Office.
On which browser?
And keep in mind, Google Docs is actually trying to use the HTML DOM. This wouldn't have to.
I can't imagine that a full JS application could replace some binary application.
I don't know about you, but even if Google Docs is slow, it's still fast enough that I don't really care. (My bigger beef with Docs is that I already have OpenOffice, and I want to store my files locally.) But there you go -- that's a JS application replacing a "binary" application.
And people can and do write games in.NET -- I think it's called XNA.
Keep in mind, no application is written in binary. They're written in languages that compile to machine code (binary), but the language itself isn't. Recent implementations of JavaScript use a JIT compiler (Just In Time, kind of like Java or.NET) to actually compile JavaScript down to machine code where it can.
It's still not as fast as C, but it's pretty fast.
installing Chrome or Firefox or another "advanced" browser on a PC running Internet Explorer brings the same potential security holes as just installing a native game into a new user account.
Except:
Chrome and Firefox are both open source.
These only need to be installed once, and can then be a client for multiple games.
Native games, unless you develop some sort of package manager, will present the same security risks for each game.
I'm pretty sure we've been over this.
In many cases that I've worked with, "what" is nearly as complex as the "how", unless by "what" you mean a specific input and the corresponding output. In my experience, testing a set of (input, output) pairs lacks coverage: good for finding regressions but not for finding bugs you don't already know about.
That's pretty much exactly what I mean -- input and output. Or, behavior given a set of input.
But this is also just the primitives -- input and output are pretty much what all programs generalize to. I tend to do integration tests ("acceptance tests"?) much more often than unit tests.
However, I do disagree with:
Test cases are often more likely to contain errors than the code being tested.
It just doesn't fit my experience -- at least, counting undetected errors -- those "silent horrors".
By that I mean, if I can get the test to run successfully, it generally doesn't have bugs. If a test fails, the bug could be in the test or in the code, but at least I know about it -- and the test is simple enough that I can usually tell where the bug is.
people are really lax when writing tests, and tests are boring, and tests aren't normally elegant.
That's a matter of discipline, and again, look at rspec. Tests can be beautiful.
The "not elegant" may refer to the fact that tests often won't be particularly DRY. This is deliberate -- making things more explicit makes it easier to verify what's going on, and avoiding typical code-reuse things (sometimes even to the point of looping) means you're also testing for bugs in how you use those constructs.
The page seems to be full of people agreeing with me:
My experience is that bugs in tests causing them to print an error at first run, even though the production code is correct, are quite often. But this takes seconds to find them and fix and gives me more confidence in my production code. There was exactly one test from more than 200 (currently, much more) in my previous project which succeeded while production code was wrong.
And for that matter:
Just a reminder. In XP UnitTests, one starts with a failing test. This would seem to eliminate the likelihood of a false positive. Before I have written any of the application code, I know that my test will report failure. I then write the test code and verify it will also report success.
Granted, this isn't necessarily true -- tests can fail, then succeed, and still be insufficient. But test-driven development does tend to lead to comprehensive and accurate coverage.
And finally:
The scenario where a bug in the test masks a bug in the code is likely when there are bugs in the programmer's brain.
And if the bug is in my brain, I find that debugging tools aren't nearly as useful as thinking about it -- though they are useful.
Suppose that a 4G mobile connection can actually reach a tenth of 100 Mbps. Sustaining that rate for even an hour on a mobile connection is enough to use up almost the entire 5 GB monthly cap and put the user into a cost-prohibitive overage.
For mobile, you'd want a much lighter version of the game anyway -- the GPU in an iPhone can't handle what a desktop PC can.
And while I agree that this is an issue, I think one way to force US carriers to ca
Yes, I missed this point. I have never played Microsoft Halo 2 or any Jak game.
Jak and Daxter, Jak II, Jak III, Halo 2...
And countless other games -- World of Warcraft comes to mind, though I suppose that's mostly loading from disk, and they aren't particularly smart when navigating to instances or other continents.
From the Content Security Policy page:
eval and related functions make trivial the task of generating code from strings, which commonly come from untrusted sources, are loaded via insecure protocols, and can become tainted with attacker controlled data.
Keep in mind, this is optional to enable. It also kills data URIs, and other interesting properties. And the entire justification is that strings can come from untrusted sources, via insecure protocols, which is a pretty brain-dead specification -- the browser can't figure out if they do come from a trusted source, via a secure protocol?
Except in a "multiplayer and online" game, other players would be shooting you while the spinner runs.
Which is not particularly different than any other kind of lag.
Provided that the game can successfully guess what room the user is going to enter next. Or did you mean "prefetch all rooms that the player could enter from here"?
I mean, prefetch all rooms, starting with the closest, in cases with a finite world. To allow for a potentially infinite world (where one room could link to another on a different server, or rooms are generated, etc), prefetch a configurable amount, based on an estimate of how quickly the player can move.
I'm still not seeing how this sounds like too much bandwidth. I suppose it depends on the game you're trying to build, but again, I could stream Half-Life on 1 mbit DSL. It took somewhere between ten and thirty seconds to download a level, and many times that to play through a level -- going room-by-room, especially in a linear game like that, I'd expect it to easily stream -- remember, 400 megs total for a game that, by one person's estimate, was seven and a half hours. Rounding up to 8, if you can download 50 megs in an hour -- less than a megabyte per minute, looks to be under 150 kilobits per second.
I can see where you'd be skeptical of the initial load time, and I base that mostly on guessing and the fact that it's never really been tried. But after that, Half-Life is less than 150 kilobits per second -- can't stream it on dialup, but just about any high speed connection should be able to handle it.
So, if we were to limit it to games of about that graphical intensity, it seems easily doable. And if you remember Half-Life, or the original Counter-Strike, or Natural Selection, I think that would be worth it.
The same person estimate 8 hours for Half-Life 2, which requires something like 4.5 gigs -- a little over 10 times the size. Which also means anyone of around 2-3 megabits can stream it -- and 6 megabits on cable is pretty common.
Not "next gen" enough? But I don't know any PC games, next gen or not, which require more than a DVD -- so unless the game is really short playtime, or a ton of teleporting around, it should be streamable. (Note that teleporting isn't necessarily a problem for streaming -- just make the teleport some sort of portal, and let the engine treat it as an attached room.)
With a bit of intelligence, you could gracefully degrade with a lack of bandwidth, just as games can currently scale (though not always automatically) to faster and slower GPUs (by adjusting level of detail, effects, etc). From what I hear, Silverlight does this for video, so that's not entirely a new idea either.
Sounds like at least one very misleading rejection. The author I mentioned had an "it's an external framework" rejection about their generated app -- which very clearly wasn't relying on any external framework installed on the device, only one to use the generated code -- when what they meant was "you're using an internal framework."
Add to this the fact that they rejected an app that contained the name of the framework, but accepted the exact same app with that name replaced with something else.
They don't examine every bite of your app though because that would take way too much time.
"bite" -- heh heh.
But seriously, they could've been a lot more accurate -- just ask for source code, grep through that for UIWebView. Or they could've mentioned UIWebView in the rejection, instead of talking about "external frameworks".
they open the door to even shittier apps and hellishly non-native interfaces.
So does any turing-complete language with a decent graphics API. In other words, so does Objective C.
I don't see why another language is a problem as long as Apple requires native UIs using Cocoa, and actively polices the app store.
Java is *still* slow,
Citation needed.
lowest common-denominator shit.
Which iFart isn't?
Can you imagine if we had "normal" cell phone programs on the iPhone instead of people taking the time to do native versions?
We'd actually have portable apps! What a novel idea! Someone would be able to develop an iPhone app, and then after Apple rejects it for some bullshit reason, they can actually go deploy it on Blackberry, Symbian, Palm, or Android!
The Wii operating system creates the equivalent of a separate user for each disc or installed channel. I wonder why PC operating systems don't do something similar... Ideally, you'd create a separate user to run an untrusted application, leaving operating system defects and driver defects as the major vector for attacks.
It would break tons of existing games, and it still wouldn't solve the security issue -- a driver bug would be just as dangerous here as it would be with WebGL. I don't see what the browser hurts in terms of security -- indeed, it adds something, by running each game as entirely managed code, in a VM that's already been hardened by real-world usage.
Ideally, a browser could run each page as an unprivileged user, so they've got the browser's built-in protection plus the OS protection. I believe Chrome does this.
In WebGL, you have to break the browser or GL itself. In your proposal, you can use any local exploit in the OS.
It takes a program written in JavaScript a lot longer to decompress this data than it would take an equivalent program written in C.
Depends how much data it is, and how it's compressed -- in particular, gzip is handled by the browser, as is image compression.
If we're talking about generation, sure, but it's not as much slower as you'd think, and I believe it's still fast enough -- that 96k took forever to load because it generated the entire game first. Plenty of demoscene demos do everything dynamically.
How would a video game's design work around a monthly transfer cap without the game being either an MMORPG or a clever simulation of one
Even if it is an MMORPG, you'd be relying heavily on browser cache.
There are a lot of beginnings in a game: the main menu, the character builder, the mission briefing, the first room, the second room, etc.
Each of which you spend some amount of time in, during which the other "beginning" can be loaded.
And "first room / second room", really? Did you miss the point about Halo 2? (Or any of the Jak games, for that matter.)
What would multiplayer have to do with whether a game is designed for offline mode or not?
Sorry, I should've been clear -- multiplayer and online.
From what I've gathered reading critiques of JavaScript, it has no command to "include" code, other than writing another element to the document, which isn't asynchronous in many browsers.
*facepalm*
It's got eval. It's got XMLHttpRequest, which can retrieve arbitrary text over HTTP. Is it that hard to figure out how those go together?
Then open one of the doors and see black space behind it while the room downloads.
Which would be similar to watching a YouTube movie and getting the little spinner.
The answer is similar: With enough bandwidth, you'll already have that room buffered before you open the door.
JavaScript is ECMAScript on top of the CSS and HTML DOM. ActionScript since around Flash 6 is ECMAScript on top of the SWF DOM.
Actually, Flash 7 added ActionScript 2.0, which is ECMAScript -- plus some "enhancements". And they've been enhancing it since then.
It shows that the implementor is unwilling to learn.
Wow. So you just admitted my other point, that is, that another implementation language automatically implies half-assed ports.
Is that really what you meant?
No, that's my experience.
In your experience, you've never seen a good port, or a good Mac app developed using a third-party framework?
I sure as hell don't want to see them on the iPhone.
You'd rather not have an app at all than have a half-assed port?
And I sure as hell prefer to have choices of implementation language, even if others might develop it, then be forced back a decade or so in language development to use Objective C when there are better choices available.
There may be limitations in what can be concatenated.
We were talking about Javascript. There shouldn't be any problem concatenating multiple script files together into a single script file. (And, for that matter, running it through a minifier and serving it via gzip.)
For example, textures used as CSS sprites can't be scaled.
Granted -- or at least, not easily. I believe you can render HTML to a Canvas element -- thus, if you can render it, you can scale it.
But what does this have to do with concatenating Javascript files?
Have you any evidence that Internet Explorer does "know how to make multiple requests at once"?
In its default configuration, I believe it still defaults to 2 at once for HTTP 1.1, and 4 for HTTP 1.0. And this can be adjusted. Source.
the bugs are in the translation of the spec from English to code in the tests, just as they would be in the translation of the spec from English to code in the actual product.
You really don't see how it could possibly be easier to code a test that matches a spec, versus an actual product that matches a spec? I mean, we agree that tests and formal specs both define what, not how? And the actual product must necessarily define how?
For that matter, have you seen rspec? It's possible to go pretty much directly from user stories (management-readable specs) to executable code.
Anecdotally, I can say that I've very, very rarely had more bugs in the tests than I do in actual code, and I can't ever remember a bug in the test that was silently ignored -- bugs in my tests lead to test failures. The only way a bug silently sneaks into production, where I need robust debugging tools, is where I didn't test something, not where I tested something incorrectly.
I do appreciate a decent debugger, but if I had to choose, I'd choose a robust test suite over a debugger any day.
Nobody I know in Fort Wayne, Indiana, a city of 200,000 people, has over 50 Mbps Internet to the home.
Which is still close to that, and fast enough to stream a DVD.
Oh, and I've got 100 mbit Internet, at a reasonable price, in Fairfield, Iowa, a city of 10,000 people.
Point is that even a tenth of that is easily sufficient.
Where an enemy pops up and kills the player's character before the enemy's texture finishes downloading.
Ah, interesting. Also can't remember ever actually seeing that.
It's also strange that you'd have this, yet not have similar things happening in the environment -- especially as I remember this being talked about in relation to the environment, not the enemies.
I mean, it's not as if that's the only creature that could singlehandedly overpower a human, even the only one that could swallow us whole. Should we have killed all the lions, tigers, and bears?
I would love to have seen one of these in a zoo.
Of course, the fact that they're gone means we can actually go to New Zealand safely...
Well, you're saying, no problem with a framework as long as it's embedded in the bundle. What if I want one that preprocesses something?
PhoneGap was an example of this -- it generated code to use UIWebView. Apple claimed the issue was UIWebView, and rejected many PhoneGap apps -- yet if you took the same app, replaced the text "PhoneGap" with anything else throughout, and resumbitted it, you might get approved.
I'm not entirely sure what the current policy is, but that's evidence that points to them disliking frameworks in general.
Slashdot Mirror
Anything that is wanted by the community will likely find its way in.
Unless the community gets bored and moves on to languages like Scala, Clojure, Ruby, etc, which already have what they want.
You see, the Java world runs like a Democracy. People don't like Swing and eventually there's SWT.
And this is different than anything except Delphi, how?
In the MS world, you're just plain stuck.
...until you realize there's Mono.
Also, half the things you mentioned (Swing, SWT, JSP, Struts, EJB, Hibernate...) are just frameworks. Just because .NET comes from Microsoft and ASP comes from Microsoft doesn't mean you can't write web services in .NET without ASP -- or without IIS, for that matter.
But again -- anonymous fucking functions. Javascript has it. Lisp has it. Ruby has it. Perl has it. C# has it. Smalltalk has it. Hell, even C has it -- this is not exactly a new idea.
Java can sort of kludge it together with anonymous classes. And it looks absolutely nothing like it does in C# -- even Javascript manages to make it look better than Java.
Seriously, show me the Java equivalent to:
Or maybe:
Contrived examples? Sure. But I'm sorry, your "language that looks 99% the same as Java" actually looks nothing like Java, unless you claim JavaScript "looks 99% the same as Java", in which case:
The iPod was a 20-year-later elaboration of the Sony Walkman.
*facepalm*
You know, there used to be this thing called an mp3 player, and later a portable music player. They're still around, but as soon as the iPod got popular, these other things like the Rio and the Nomad were suddenly seen as "iPod clones", even when they predated the iPod.
The innovation of the iPod was making it simple enough for everyone to use, not inventing the thing itself. The innovation of the Walkman was making it portable in the first place.
When Java adds something as simple as anonymous functions, I'll concede your point.
And no, I'm not an MS fan. I like Ruby. But I think you're crazy if you don't at least see how a lambda closure -- especially a dirt simple lambda closure, in a tiny bit of syntax instead of a class and a half -- is not at all like Java.
Its a lot less of an effort to use a mouse than it is to use a touchscreen.
I think that depends very much where the touch is. For example, the touchpad on my laptop takes very little effort to use.
On the other hand, I absolutely cannot play FPS reasonably on the thing, so maybe you're right.
Taste isn't for everybody.
Nor is common courtesy, obviously.
There has never been a time when those were your only two options.
What would you suggest?
So even if you're serving a page over HTTPS, a malicious user of your system might have created the elements.
Still doesn't mean I'm planning to run eval on any string that I didn't create, or that a script I created didn't create.
And this XHR-then-eval technique is something I've used in real apps. I doubt I'd give it up without a replacement.
Most lag in online games isn't as sensitive to bandwidth as the kind of lag you get from streaming the textures.
True -- it is, however, sensitive to latency (which can be sensitive to bandwidth), as well as local RAM, CPU, disk (sometimes), and video capabilities.
A 3 Mbps link is about as fast as the 2x CD-ROM drive in an original PlayStation. So I guess if people come in with expectations of PS1 quality, which is still an upgrade from the roughly GBA quality of DHTML, 2D canvas, or SWF, they might accept it.
Right. Missing a couple of points, though:
It's been tried. Remember how long it took PS1 games to boot to the menu?
You mean, after all the logos that have to go into games? Yeah, I guess interstitials would cause that, too.
But no, I don't think we've seen anyone try to reduce boot time of a game to where it can be quite that kind of impulse thing (the way YouTube is).
People will see loading every time they play, just like on the PlayStation, because most people aren't going to let a single web site cache hundreds of megabytes.
...why not? I mean, if the alternative is to actually download hundreds of megabytes and store it permanently, why wouldn't I just crank up my browser's cache to use, oh, 10, 20, 50 gigs? I've got the space, and so do most people -- the way that space would otherwise be used is with games, massive amounts of audiovisual content, or virtual machines.
It's possible there are uses I'm not thinking of, but really, even netbooks come with at least some 8 gigs, laptops tend to be around 300 gigs, and it's hard to buy a hard drive with less than 80 gigs anymore.
Keep in mind, it's just browser caching -- which means it also benefits from a caching proxy (Squid, say), and it means it's not the site doing anything, it's the browser caching. Every browser I've tested this on can cache XHRs as easily as anything else.
Then we'll have to agree to disagree.
Back when I had a Mac, I much preferred having NeoOffice to having nothing but TextEdit. That's kind of a no-brainer.
will be running on JS which isn't comparable in speed to binary or ASM programs.
But it is comparable to Python, and people have written interesting GL games in Python.
It doesn't have to be as fast, it just has to be fast enough.
Google Docs is slower than MS Office or even Open Office.
On which browser?
And keep in mind, Google Docs is actually trying to use the HTML DOM. This wouldn't have to.
I can't imagine that a full JS application could replace some binary application.
I don't know about you, but even if Google Docs is slow, it's still fast enough that I don't really care. (My bigger beef with Docs is that I already have OpenOffice, and I want to store my files locally.) But there you go -- that's a JS application replacing a "binary" application.
And people can and do write games in .NET -- I think it's called XNA.
Keep in mind, no application is written in binary. They're written in languages that compile to machine code (binary), but the language itself isn't. Recent implementations of JavaScript use a JIT compiler (Just In Time, kind of like Java or .NET) to actually compile JavaScript down to machine code where it can.
It's still not as fast as C, but it's pretty fast.
installing Chrome or Firefox or another "advanced" browser on a PC running Internet Explorer brings the same potential security holes as just installing a native game into a new user account.
Except:
I'm pretty sure we've been over this.
In many cases that I've worked with, "what" is nearly as complex as the "how", unless by "what" you mean a specific input and the corresponding output. In my experience, testing a set of (input, output) pairs lacks coverage: good for finding regressions but not for finding bugs you don't already know about.
That's pretty much exactly what I mean -- input and output. Or, behavior given a set of input.
But this is also just the primitives -- input and output are pretty much what all programs generalize to. I tend to do integration tests ("acceptance tests"?) much more often than unit tests.
However, I do disagree with:
Test cases are often more likely to contain errors than the code being tested.
It just doesn't fit my experience -- at least, counting undetected errors -- those "silent horrors".
By that I mean, if I can get the test to run successfully, it generally doesn't have bugs. If a test fails, the bug could be in the test or in the code, but at least I know about it -- and the test is simple enough that I can usually tell where the bug is.
people are really lax when writing tests, and tests are boring, and tests aren't normally elegant.
That's a matter of discipline, and again, look at rspec. Tests can be beautiful.
The "not elegant" may refer to the fact that tests often won't be particularly DRY. This is deliberate -- making things more explicit makes it easier to verify what's going on, and avoiding typical code-reuse things (sometimes even to the point of looping) means you're also testing for bugs in how you use those constructs.
The page seems to be full of people agreeing with me:
My experience is that bugs in tests causing them to print an error at first run, even though the production code is correct, are quite often. But this takes seconds to find them and fix and gives me more confidence in my production code. There was exactly one test from more than 200 (currently, much more) in my previous project which succeeded while production code was wrong.
And for that matter:
Just a reminder. In XP UnitTests, one starts with a failing test. This would seem to eliminate the likelihood of a false positive. Before I have written any of the application code, I know that my test will report failure. I then write the test code and verify it will also report success.
Granted, this isn't necessarily true -- tests can fail, then succeed, and still be insufficient. But test-driven development does tend to lead to comprehensive and accurate coverage.
And finally:
The scenario where a bug in the test masks a bug in the code is likely when there are bugs in the programmer's brain.
And if the bug is in my brain, I find that debugging tools aren't nearly as useful as thinking about it -- though they are useful.
Suppose that a 4G mobile connection can actually reach a tenth of 100 Mbps. Sustaining that rate for even an hour on a mobile connection is enough to use up almost the entire 5 GB monthly cap and put the user into a cost-prohibitive overage.
For mobile, you'd want a much lighter version of the game anyway -- the GPU in an iPhone can't handle what a desktop PC can.
And while I agree that this is an issue, I think one way to force US carriers to ca
Yes, I missed this point. I have never played Microsoft Halo 2 or any Jak game.
Jak and Daxter, Jak II, Jak III, Halo 2...
And countless other games -- World of Warcraft comes to mind, though I suppose that's mostly loading from disk, and they aren't particularly smart when navigating to instances or other continents.
From the Content Security Policy page:
eval and related functions make trivial the task of generating code from strings, which commonly come from untrusted sources, are loaded via insecure protocols, and can become tainted with attacker controlled data.
Keep in mind, this is optional to enable. It also kills data URIs, and other interesting properties. And the entire justification is that strings can come from untrusted sources, via insecure protocols, which is a pretty brain-dead specification -- the browser can't figure out if they do come from a trusted source, via a secure protocol?
Except in a "multiplayer and online" game, other players would be shooting you while the spinner runs.
Which is not particularly different than any other kind of lag.
Provided that the game can successfully guess what room the user is going to enter next. Or did you mean "prefetch all rooms that the player could enter from here"?
I mean, prefetch all rooms, starting with the closest, in cases with a finite world. To allow for a potentially infinite world (where one room could link to another on a different server, or rooms are generated, etc), prefetch a configurable amount, based on an estimate of how quickly the player can move.
I'm still not seeing how this sounds like too much bandwidth. I suppose it depends on the game you're trying to build, but again, I could stream Half-Life on 1 mbit DSL. It took somewhere between ten and thirty seconds to download a level, and many times that to play through a level -- going room-by-room, especially in a linear game like that, I'd expect it to easily stream -- remember, 400 megs total for a game that, by one person's estimate, was seven and a half hours. Rounding up to 8, if you can download 50 megs in an hour -- less than a megabyte per minute, looks to be under 150 kilobits per second.
I can see where you'd be skeptical of the initial load time, and I base that mostly on guessing and the fact that it's never really been tried. But after that, Half-Life is less than 150 kilobits per second -- can't stream it on dialup, but just about any high speed connection should be able to handle it.
So, if we were to limit it to games of about that graphical intensity, it seems easily doable. And if you remember Half-Life, or the original Counter-Strike, or Natural Selection, I think that would be worth it.
The same person estimate 8 hours for Half-Life 2, which requires something like 4.5 gigs -- a little over 10 times the size. Which also means anyone of around 2-3 megabits can stream it -- and 6 megabits on cable is pretty common.
Not "next gen" enough? But I don't know any PC games, next gen or not, which require more than a DVD -- so unless the game is really short playtime, or a ton of teleporting around, it should be streamable. (Note that teleporting isn't necessarily a problem for streaming -- just make the teleport some sort of portal, and let the engine treat it as an attached room.)
With a bit of intelligence, you could gracefully degrade with a lack of bandwidth, just as games can currently scale (though not always automatically) to faster and slower GPUs (by adjusting level of detail, effects, etc). From what I hear, Silverlight does this for video, so that's not entirely a new idea either.
you probably mean your internet can do 6 Mbps (mega bits per second) - the Xbox drive throughput is in _Bytes_ per second?
Nope.
Let me break it down for you: I have 100 mbit Internet. I've gotten ten or eleven megabytes per second to servers I control on the same fiber network.
external frameworks distributed separately,
Sounds like at least one very misleading rejection. The author I mentioned had an "it's an external framework" rejection about their generated app -- which very clearly wasn't relying on any external framework installed on the device, only one to use the generated code -- when what they meant was "you're using an internal framework."
Add to this the fact that they rejected an app that contained the name of the framework, but accepted the exact same app with that name replaced with something else.
I am not sure if this works on all browsers.
What, reading text files? Of course it does.
When You run everything (file reading, rendering, back face sculling, front face sculling etc) from JS then it will be slow.
The word you're looking for is "culling". And in a well designed engine, that's really not where you're going to be spending most of your time, is it?
Uhm... Middle Earth?
They don't examine every bite of your app though because that would take way too much time.
"bite" -- heh heh.
But seriously, they could've been a lot more accurate -- just ask for source code, grep through that for UIWebView. Or they could've mentioned UIWebView in the rejection, instead of talking about "external frameworks".
they open the door to even shittier apps and hellishly non-native interfaces.
So does any turing-complete language with a decent graphics API. In other words, so does Objective C.
I don't see why another language is a problem as long as Apple requires native UIs using Cocoa, and actively polices the app store.
Java is *still* slow,
Citation needed.
lowest common-denominator shit.
Which iFart isn't?
Can you imagine if we had "normal" cell phone programs on the iPhone instead of people taking the time to do native versions?
We'd actually have portable apps! What a novel idea! Someone would be able to develop an iPhone app, and then after Apple rejects it for some bullshit reason, they can actually go deploy it on Blackberry, Symbian, Palm, or Android!
The Wii operating system creates the equivalent of a separate user for each disc or installed channel. I wonder why PC operating systems don't do something similar... Ideally, you'd create a separate user to run an untrusted application, leaving operating system defects and driver defects as the major vector for attacks.
It would break tons of existing games, and it still wouldn't solve the security issue -- a driver bug would be just as dangerous here as it would be with WebGL. I don't see what the browser hurts in terms of security -- indeed, it adds something, by running each game as entirely managed code, in a VM that's already been hardened by real-world usage.
Ideally, a browser could run each page as an unprivileged user, so they've got the browser's built-in protection plus the OS protection. I believe Chrome does this.
In WebGL, you have to break the browser or GL itself. In your proposal, you can use any local exploit in the OS.
It takes a program written in JavaScript a lot longer to decompress this data than it would take an equivalent program written in C.
Depends how much data it is, and how it's compressed -- in particular, gzip is handled by the browser, as is image compression.
If we're talking about generation, sure, but it's not as much slower as you'd think, and I believe it's still fast enough -- that 96k took forever to load because it generated the entire game first. Plenty of demoscene demos do everything dynamically.
How would a video game's design work around a monthly transfer cap without the game being either an MMORPG or a clever simulation of one
Even if it is an MMORPG, you'd be relying heavily on browser cache.
There are a lot of beginnings in a game: the main menu, the character builder, the mission briefing, the first room, the second room, etc.
Each of which you spend some amount of time in, during which the other "beginning" can be loaded.
And "first room / second room", really? Did you miss the point about Halo 2? (Or any of the Jak games, for that matter.)
What would multiplayer have to do with whether a game is designed for offline mode or not?
Sorry, I should've been clear -- multiplayer and online.
From what I've gathered reading critiques of JavaScript, it has no command to "include" code, other than writing another element to the document, which isn't asynchronous in many browsers.
*facepalm*
It's got eval. It's got XMLHttpRequest, which can retrieve arbitrary text over HTTP. Is it that hard to figure out how those go together?
Then open one of the doors and see black space behind it while the room downloads.
Which would be similar to watching a YouTube movie and getting the little spinner.
The answer is similar: With enough bandwidth, you'll already have that room buffered before you open the door.
JavaScript is ECMAScript on top of the CSS and HTML DOM. ActionScript since around Flash 6 is ECMAScript on top of the SWF DOM.
Actually, Flash 7 added ActionScript 2.0, which is ECMAScript -- plus some "enhancements". And they've been enhancing it since then.
If that was the problem, why were PhoneGap apps approved, so long as they removed the string "PhoneGap" from the app?
It shows that the implementor is unwilling to learn.
Wow. So you just admitted my other point, that is, that another implementation language automatically implies half-assed ports.
Is that really what you meant?
No, that's my experience.
In your experience, you've never seen a good port, or a good Mac app developed using a third-party framework?
I sure as hell don't want to see them on the iPhone.
You'd rather not have an app at all than have a half-assed port?
And I sure as hell prefer to have choices of implementation language, even if others might develop it, then be forced back a decade or so in language development to use Objective C when there are better choices available.
There may be limitations in what can be concatenated.
We were talking about Javascript. There shouldn't be any problem concatenating multiple script files together into a single script file. (And, for that matter, running it through a minifier and serving it via gzip.)
For example, textures used as CSS sprites can't be scaled.
Granted -- or at least, not easily. I believe you can render HTML to a Canvas element -- thus, if you can render it, you can scale it.
But what does this have to do with concatenating Javascript files?
Have you any evidence that Internet Explorer does "know how to make multiple requests at once"?
In its default configuration, I believe it still defaults to 2 at once for HTTP 1.1, and 4 for HTTP 1.0. And this can be adjusted. Source.
the bugs are in the translation of the spec from English to code in the tests, just as they would be in the translation of the spec from English to code in the actual product.
You really don't see how it could possibly be easier to code a test that matches a spec, versus an actual product that matches a spec? I mean, we agree that tests and formal specs both define what, not how? And the actual product must necessarily define how?
For that matter, have you seen rspec? It's possible to go pretty much directly from user stories (management-readable specs) to executable code.
Anecdotally, I can say that I've very, very rarely had more bugs in the tests than I do in actual code, and I can't ever remember a bug in the test that was silently ignored -- bugs in my tests lead to test failures. The only way a bug silently sneaks into production, where I need robust debugging tools, is where I didn't test something, not where I tested something incorrectly.
I do appreciate a decent debugger, but if I had to choose, I'd choose a robust test suite over a debugger any day.
Nobody I know in Fort Wayne, Indiana, a city of 200,000 people, has over 50 Mbps Internet to the home.
Which is still close to that, and fast enough to stream a DVD.
Oh, and I've got 100 mbit Internet, at a reasonable price, in Fairfield, Iowa, a city of 10,000 people.
Point is that even a tenth of that is easily sufficient.
Where an enemy pops up and kills the player's character before the enemy's texture finishes downloading.
Ah, interesting. Also can't remember ever actually seeing that.
It's also strange that you'd have this, yet not have similar things happening in the environment -- especially as I remember this being talked about in relation to the environment, not the enemies.
once I've plugged two keyboards into a hub, both players will expect to be able to use the same keys (e.g. player 1 arrows vs. player 2 arrows).
True. Just pointing out that it is possible to plug two keyboards in, and have each player use separate keys.
wired and wireless ISPs have dragged their feet compared to Japan, Korea, and western Europe?
I said "steadily". I didn't say "fast".
Good points otherwise, though.
Not to reply to myself, but...
There's more.
Or the garage.
It would be cool if it was alive today...
I mean, it's not as if that's the only creature that could singlehandedly overpower a human, even the only one that could swallow us whole. Should we have killed all the lions, tigers, and bears?
I would love to have seen one of these in a zoo.
Of course, the fact that they're gone means we can actually go to New Zealand safely...
Well, you're saying, no problem with a framework as long as it's embedded in the bundle. What if I want one that preprocesses something?
PhoneGap was an example of this -- it generated code to use UIWebView. Apple claimed the issue was UIWebView, and rejected many PhoneGap apps -- yet if you took the same app, replaced the text "PhoneGap" with anything else throughout, and resumbitted it, you might get approved.
I'm not entirely sure what the current policy is, but that's evidence that points to them disliking frameworks in general.
I do kind of hope you're right, though.