As for tools, smalltalk provides the tools, they are just different than what is used for other languages. The tools for smalltalk (the browser, monticello, the file list etc) work really well for smalltalk.
That's great, but they are also different than the tools for any other language. I want to be able to use my favorite text editor, my favorite version control system, etc.
there is no need for any others - nearly 40 years of development has produced a very efficient and intuitive environment.
And nearly 40 years of development has produced a multitude of general-purpose tools that make me more productive with any language.
In my opinion the only place Java beats Smalltalk
As a language? No contest, you're right.
But with Java, I compile source to bytecode representations, zip those up, and distribute them. With Smalltalk, unless I'm misunderstanding something, I run that program, edit the running program if I want to make a change, and save a bytecode snapshot of a running program, then distribute that -- which seems somewhat cumbersome if someone else wants to import my program into their Smalltalk environment.
I don't get why an object has to care about what class a reference dereferences to, and why methods have to have all that type declaration fluff around them.
I agree completely, which is why I use Ruby when I can.
Python normally caches the compiled bytecode of imported modules in.pyc files and only recompiles them as necessary. It also provides modules for doing this beforehand, which can also be used like programs with python -m, which most distros will do when packages with Python code are installed, because you won't have write access to/usr/lib (or wherever) as a normal user. It is also capable of directly running bytecode even without a corresponding source file.
Sorry, I forgot about that. I suspect it was the GIL that was the deal-breaker here, not to mention the fact that it was tied to a single platform.
I don't know about Perl and Ruby, not being particularly familiar with them, but I wouldn't be surprised if they could do something similar.
They can't. Perl6 will be able to, if it's ever released.
JavaScript can't really be compared to any of the others, as the language doesn't have any standard implementation, de facto or otherwise, and thus one cannot sensibly speak of the features of "its implementation".
Well, we can talk about the fact that Google's v8 (part of Chrome) JIT-compiles to native code, and Firefox and Safari both contain relatively fast Javascript engines which have got to be doing something similar.
You are going to have to provide different packages for all the different platforms you wish to support,
Not necessarily. I suppose it's the case right now that you can't expect users to know what to do if you just give them a jar, but as a contrived example, suppose I distributed a single.deb and a single.rpm. If that contained either source or bytecode, it would work on pretty much all Linux platforms. If it contained machine code, it would be bound to a specific architecture.
using the same binary for all of them really only saves you compilation time,
That can be significant, but the primary motivation here was a new platform which would allow distribution of cross-platform proprietary apps.
The idea was that there are still some apps which don't make sense as web apps (yet) -- my motivation at the time was games -- and if people are going to be building these at all, I'd much rather they be inherently, automatically cross-platform than Windows-only.
Granted, but I was wanting to do game development -- you're going to need a desktop client of some sort. The idea was to have a very small set of native bindings, and have the entire game be portable.
Taken a step further, which I didn't mention (but did consider while evaluating these VMs), I wanted to be able to sandbox a program without losing too much performance. The idea here was to be able to download a game targeting my meta-platform on any platform (Windows, Linux, OS X, consoles) without worrying about security, and to be able to develop such a game without worrying about portability.
If I was going to try that again, I'd probably use WebGL -- but notice, the problem hasn't disappeared, and some new problems have cropped up, like the reluctance of proprietary software developers to allow their source code to be distributed -- they'd be much more comfortable with some sort of bytecode representation.
If Java get closures, what are you missing in Java?
Others have listed other reasons, but let's see...
It's statically typed. Understand, I don't mind strict typing (Ruby is strictly typed), I just get annoyed at having to declare variable types all the time.
The generics is a mess -- as u17 says, it's a hack, and it's also incredibly difficult to understand, and requires a lot of heavy thinking and planning about types and interfaces. Compare to what you get for free from a language like Ruby.
And most of that mess is in the name of backwards compatibility. Excuse me, but do we care that much about backwards compatibility? I suppose it made sense at the time, and I suppose I can't blame them, but it cripples the language today.
Java's threading API sucks. Aside from the overhead u17 pointed out, it's still the same old threading API. Compare to something like Erlang.
Reflection? Easy to use? You've obviously never used a language where it's actually easy to use, like, say, Ruby.
Aside from closures, it's missing Lisp's macros, which take that idea to a whole other level.
And the syntax is brittle -- no operator overloading, for one -- it'd be very difficult to correct any of what I've just said with a library. For example: In most sane languages, a == b has well-defined semantics of comparing the values of a and b. In Java, it compares the values for numerical primitives, and the references for everything else. Because of this, you end up with Object.equals(), which is much more verbose and cumbersome to use, and incurs boxing/unboxing overhead when used with primitives.
Yet despite all that, Java does do some overloading of its own with Strings -- it overloads +, but not ==.
So you can imagine, just about anything interesting I'd want to add to the language, which would be an internal DSL in smarter languages like Ruby and Lisp, would be a mess of verbose library calls in Java.
Similar problems: You can use enumerations and integers for a switch statement, but you can't use strings. Because Java lacks any meaningful way to modify the primitive types, and isn't flexible enough to override case itself, you can't fix this to do what you'd expect, which is for it to use Object.equals(), or even a more verbose version that allows you to pass a Comparator.
What else...
No keyword arguments, and no sane way to add syntax for them. No built-in hash type, and thus no hash literals. Ruby doesn't have keyword arguments either, but its syntax is loose enough that you can use the builtin hashes to replace them.
No symbols/atoms, either.
No good interactive shells. Then again, do you really want an interactive shell in a language that's that friggin verbose?
Hell, verbosity deserves a category of its own. Just look at Hello World in Java. Compare to Hello World in pretty much any other language.
The built-in array type, aside from having an unnecessarily verbose literal, is also a fixed size. I suppose it's useful to have a fixed-size array, but 99% of the time, that's not what you want. Make ArrayList the default array type, have things accept Lists (or better yet, Collections) rather than arrays, and provide syntactic sugar for creating ArrayLists instead of Arrays, then tuck the actual Array type deep in some system library so programmers don't have to bother with it again... but like so many of these problems, you can't actually solve it that way without breaking the language.
Then again, u17 points out a potential problem with that -- ArrayLists, like all Collections, must store objects (and thus references) rather than the actual values. That means ArrayList<Integer> is necessarily slower and bloatier than int[] (by much more than it should be), and there's again nothing you can do about it. Contrast to Ruby -- you'd expect a construct like [1, 2, "three", 4] to be even worse, but it's actually better than an ArrayList of [1,2,3,4] in Java -- I believe it uses a
The nice thing about an assembly language for the web is that it could compile to byte-code run by a standardized virtual machine (which can be further abstracted to be a compatible, thin layer between the language and the processor).
Maybe, but JavaScript is simultaneously a horrible choice for such a language, and an excellent choice for an application development language.
we should have more options than that, especially where other niche languages have an advantage.
Can you give an example?
a language designed for multiple cores/processors
JavaScript can do that now, and it does so with message-passing. Functional languages might be interesting to try that way, but I'm not sure how efficiently they can map to a message-passing system. Erlang, maybe, but it's fundamentally an uglier language than JavaScript -- the good thing about Erlang is the VM.
The latter could be unnecessary if the compiler were advanced enough to support concurrency automatically. I am not a compiler designer,
Neither am I, but I doubt it can be done well.
Actually, CPUs do something like this already, and compilers could, I'm just skeptical about the results. Take a simple for loop iterating over an array and updating each element. How would a compiler be able to infer that to a map function, unless it's hand-optimized for specific types of for loops?
Basically, I think that if we do start talking about an "assembly language for the Web", we should go ahead and try to build one. I wouldn't know where to begin, though, to be honest -- there are two many different models to support. The only real problem I see for Javascript in the near future is multicore, and I think it's manageable, and again, with libraries and frameworks (building on top of Web Workers) rather than with a brand-new language.
Yes, and if the browser doesn't support it, it is a plugin.
All of HTML5 is also a plugin on IE, called Chrome Frame. That's not the relevant issue. The relevant issue is whether it's a standard we can agree on.
Again if Microsoft 'embeds' Silverlight into IE then because it is no longer a plugin and 'it is in line with HTML5 goals'?
They'd also have to irrevocably release all the relevant patents, and there'd still only be the one open source implementation.
There's also no particularly compelling need for Silverlight, when HTML5 presents a much more transparent way to handle video and audio, which is the main reason you'd need Silverlight in the first place.
And according to your definition, Silverlight is also crossplatform, as it runs on...
iPhone is indeed a stretch. OS X and Windows have native implementations from Microsoft, making that about as useful as Flash.
There is thus a total of one open source implementation (Mono), and there's still the issue of patents and of relevance.
HTML5 is trying to break from square box controls and external standards. If of an SVG circle or triangle and text flowing around it, this is the direction not square canvases that use masking tricks to fit on the page in anything but a 'box'.
Then how would you suggest supporting high-performance hardware-accelerated 3D rendering in that environment?
I can think of a few ways to get similar effects, but I don't know that I can think of a use case.
Let me put it another way: <video> is also part of HTML5 and also generally a 'box'. Can you think of how it could be any other way?
You also have the object access level, and WebGL is wrapped in code, you can't reach out and set the transparecy of an 'internal' object being rendered in the scene outside via CSS.
That is a legitimate criticism. I'm not sure there's a good answer, though, especially one that doesn't have serious performance implications.
I don't dislike WebGL, although I would rather put more effort into getting GPU accelerated browsers...
There's still a question of how to render 3D.
Having SVG and other good things of HTML5 and dynamic rendering running on the GPU already then there really isn't a need for WebGL.
That depends what you're doing. Would you really attempt to build a game like Quake that way? Using a 2D SVG, doing all the perspective work and occlusion culling yourself instead of letting OpenGL handle it?
What bothers me about this article and news story is that Google and users are acting like Chrome is rendering Quake in HTML5, which it is not doing, it is only doing the final paint to an HTML5 canvas. This is not a demonstration of HTML5 or Chrome being good at HTML5.
Also fair, it would've been nice if they specified WebGL instead of HTML5, as the way it's worded now suggests WebGL is part of HTML5, which it's not.
I suppose I'm a bit impatient. What bothers me the most about this is that we had the technology to do this in 1999 -- to make something like a web browser that would really be an application-browser -- and I've been waiting a long time to make a truly web-based videogame. This has a shot at it -- if your browser already has WebGL enabled, I could streamline a game to load your starting point within the world in seconds.
I remember taking a long, hard look at the state of various VMs awhile back, and here's what I came up with:.NET isn't a bad design, but it's entirely controlled by Microsoft. Rotor doesn't change that at all. Mono changes it a little, but Mono (at least back then) wasn't really a great platform in its own right -- not enough tools, not enough reason to use it, always playing catch-up. Plus, there's the whole patent issue. On top of all of that, it was never really designed to be cross-platform, and instead seems to be primarily aimed at creating native apps.
The various "scripting" languages have been moving towards VM architectures, and some are quite good, but none that I know of actually feature any kind of ahead-of-time compilation, even to bytecode. That includes Perl, Python, Ruby, JavaScript, and plenty of others.
Lisps are better, but they generally don't compile to an intermediate form -- if they compile at all, it's to something platform-specific, likely machine code.
Smalltalk is interesting, but is even more closed off than Java, and basically requires an entirely different set of tools for working with. It's not really designed to work as a text-based language.
The closest would seem to be Erlang, but it's radically different. While I know of at least one other language trying to target the Erlang VM, it's something that's really designed to work with Erlang. I'm also not entirely sure if the performance is there.
LLVM looks very, very good, but very few languages actually target it, beyond, say, C. It seems to be targeting runtime optimizations, not portability.
I probably looked at a few others I'm forgetting now...
Basically, the top two are still Java and.NET. Both present a VM that supports multiple real languages. In Java, this is by accident, it's hackish, but there are plenty of robust, mature languages other than Java which target it -- Scala, Groovy, Clojure, JRuby... In.NET, this is by design, but the more interesting other languages targeting it seem to be in an alpha state.
So Java is pretty much it. And it means we can take our fun, dynamic languages, and (eventually) compile them to Java bytecode, and create entirely cross-platform apps with no local dependencies other than Java. It means we get much of the work that's been put into optimizing Java for free -- for example, the Java garbage collector. It also means that even when designing a native app, well, Ruby just got threads in 1.9, and there's still a GIL, so no support for multicore. Python has and probably will always have a GIL. JRuby has had real, native Java threads almost as long as it's existed. Ruby has plenty of options for concurrency, but if you want to take advantage of multicore, your options are either JRuby or a unix fork(), and Ruby's GC is not COW-friendly, so fork() is potentially much more expensive than in other languages.
I don't know if Java is the way forward. I hope someone builds something cool on top of LLVM. I certainly hope Java the language dies. But the JVM is about the best we have in terms of open-source, cross-platform, compile-once-run-anywhere VMs.
The dream, from a developer's perspective, is this: In 3-5 years (this is the dream part given how fast the web changes), Javascript is an assembly language.
What? No, you had it right here:
Javascript in isolation is not as bad a language as people make it out to be,
Full stop. In fact, it's quite a pleasant language. The unpleasantness comes from this:
supporting common browsers
And that can be abstracted away with libraries.
What JavaScript needs is libraries, frameworks, and abstraction, not other languages stacked on top of it. More JQuery, Prototype, and SproutCore, and less Google Web Toolkit, Pyjamas, and HotRuby.
and fixing all bugs as you're writing it
I have no idea what you mean here.
I would kill to be able to write an application in Python, C#, or Java and know that I can compile to a package supported by >90% of people on the web.
Well, that's exactly what Google Web Toolkit is, but again, I'd suggest looking into JavaScript libraries instead.
Much like writing in assembly versus higher-level languages, writing Javascript directly will always be faster than compiling from another language. But at what cost to your time and sanity?
Not nearly as much as assembly language.
Again, it's the language. JavaScript is a decent language. Assembly Language... isn't. No matter how many frameworks you pile on top of ASM, it's not going to be pretty until you at least add a hell of a preprocessor, and at some point, we call that preprocessor a "compiler". By contrast, I've written things very quickly in JQuery, kept my sanity, and had it working easily in Chrome, Firefox, and IE, without testing in more than Chrome while developing -- it Just Worked in Firefox and IE. (And Safari, I assume.)
WebGL isn't a library, it's a binding. It does bind to native OpenGL (if the browser supports that), and while it may not be strictly HTML5, it is in line with the HTML5 goals -- to make the browser itself the platform, without relying on plugins.
If this was an HTML5 demonstration, it would be using PNGs, SVG, and CSS to create the game
Fair enough, though that would be much slower.
Wow, almost as impressive as using activex rendering DirectX content that we first saw in the freaking 1990s.
Yes, because ActiveX is a nice, cross-platform standard with multiple open source implementations... Oh wait.
Read that again until it sinks in, by the way.
Cross-platform -- WebGL runs on Windows, Linux, and OS X, at the very least, and likely on the iPhone. Your attempt to pretend this is a Google-vs-the-world thing falls flat.
Standard -- WebGL is managed by Khronos, who maintains OpenGL itself -- the working group includes Apple, Google, Mozilla, and Opera.
Multiple open-source implementations -- Firefox and Chromium both support it in some dev build or other. That also means Gecko and Webkit, which means dozens of other browsers.
WebGL embedded in a browser or used as a plug-in is NOT the browser's rendering engine doing the work.
So what?
And for what it's worth, it is useful that it ends up on a Canvas. Unless I'm mistaken, that means it is composited with the rest of the document, meaning you could (for example) draw your HUD using standard HTML and only use the GL for the 3D. Please explain why this is a bad thing.
If by XGL you mean modern compositing window managers, they're actually a performance improvement on modern hardware, and some of that "eye candy" is real usability enhancements -- everything from a drop shadow (helps make it more obvious which window is on top, and that it's a discrete window, making it easier to look at and comprehend) to expose or alt+tab with live previews (now which of my many terminals did I want? Hold alt, hit tab, watch them fly by... oh yes, that one)...
Oh, and an actual, working, performant zoom. That alone is worth it.
It's one of those hacks that is cool because it's deeply wrong, not something that is in any way sensible.
Well, yes and no.
Yes, it's deeply wrong, and it's a hack, because we're talking about a Java version of Quake2 which was ported to Google Web Toolkit, and I can't imagine that would lead to the best performance. Also, Quake2 already has a native open source client.
However, running 3D games in the browser is sensible. It's a long way from being a replacement for native games, but think about the appeal of flash games, and add relatively modern graphics capabilities to that.
Or consider an angle for an MMO -- just visit our website and you drop right into the game, no need to download anything, let alone gigabytes and gigabytes of data via BitTorrent. If we change an asset, just rely on standard HTTP cache invalidation to pick it up.
Hey, why use DirectX when you can just up the hardware reqs and run it in the browser?
*facepalm*
Not that it wouldn't up the hardware reqs, especially with the current state...
But Google is working on a standard for native code in the browser, which would make the browser a safe sandbox for entirely native, full-performance games.
And it is OpenGL. Are you seriously implying DirectX is faster than OpenGL?
And on the other end, are you seriously planning to run a 3D game in a browser on a phone?
Not only am I planning on it, I'm planning for it to work well.
Javascript is, as the name implies, a scripting language.
At the time, that distinction was relevant. It isn't anymore.
it's easy to hack something together, but as the size of the project grows, that same feature makes it harder and harder to keep the whole thing from collapsing into a rats nest lined with spaghetti.
Here we go...
You can write COBOL in any language, and you can write good code in any language. If you don't have the discipline for Javascript, you could always write a preprocessor that forces it on you, but I think you'll find that knowledgeable programmers using it on real projects don't tend to have these problems.
The awful fact is that most programmers are mediocre and need handholding from the language to produce good or even okay code.
Another fact is that this same handholding slows down good programmers until you only have mediocrity everywhere. I don't think it even succeeds in making bad programmers mediocre, as TheDailyWTF will confirm.
A good programmer in a good language can easily outperform ten bad-to-mediocre programmers in a crippled language.
Languages like Javascript or Python allow - even encourage - sloppiness, since that facilitates writing quick and dirty scripts,
or Ruby, I would guess. Yet the Ruby community seems to enforce readable, well-architected code, along with readable unit tests (specs) for every change. Say what you will about the effectiveness of testing, it sure as hell isn't sloppy, or a "quick and dirty" solution.
Do I use languages like that when I need a quick hack? Sure! That's because they're good languages, so a quick hack is going to be easier to develop in Python or Ruby than it is in C. But you can write quick hacks in C, Java, or anything else, and you can also write solid code in Python, Ruby, and even Javascript.
It doesn't exactly help that scripting languages tend to catch most errors at runtime rather than compile time,
It doesn't hurt as much as you might imagine when you have full test coverage. In fact, given full test coverage, runtime errors are compile-time errors, meaning fewer runtime errors slipping by than you'd have with a program written in a stricter language but with fewer tests.
mostly because they like to pretend that variables are untyped
That's not pretending. In languages like Javascript, the variables are. It's the objects that are typed.
yet fail if you try to do something the object doesn't support.
Duh. What did you expect?
Here's a hint: Even in Java, there are many cases where something will fail at runtime when you try to do something the object doesn't support, faster than you can say NullPointerException. Or take the standard libraries -- fail-fast iterators, plenty of stuff not designed to work well with concurrent access from multiple threads...
You seem to be assuming that we all write crazy code where no one knows what type of object we're dealing with. In practice, it's not that far off from anonymous subclasses in Java, and it's significantly faster to write, read, and reason about when we don't have to write LongClassName<OtherLongClassName<OtherReallyLongClassName>> foo = new LongClassName<OtherLongClassName<OtherReallyLongClassName>>();
Ever tried to wrap your head around Java Generics, or C++ templates, or.NET... I'm guessing generics? It starts out innocently enough, but it eventually leads to serious issues, some even cropping up at runtime, plenty leaving you scratching your head trying to figure out how to describe exactly what kind of type makes sense here, what kind of inheritance relationship, etc...
That whole nightmare goes away when you can simply declare a variable with 'var' and let the system figure it out.
Sadly, there probably isn't a password. Most users can't be bothered.
Install a physical keylogger, then come back the next day.
Boot Linux, but use it to reset the password, so that you can boot Windows and use standard Windows tools to plant the evidence -- then boot Linux again and restore the password (by hash). I'm not sure the tools exist for that last step.
Boot Linux, use it to remove the password. User probably won't notice. Then boot Windows and do all the same stuff.
Of course homeopathy won't help with serious illness, but most illnesses are not serious, and will pass by on their own. In such case, a placebo to alleviate the symptoms - or, rather, how the patient experiences the symptoms - can be the best possible help.
Perhaps, but I don't think that justifies deliberately deceiving the general public, nor spending tax dollars on what is quite literally making people feel better.
It's not bending over for Sony if you bought it for what it was designed for: gaming.
It's gaming on their terms, with (apparently) their ability to revoke anything at any time.
I don't mind that on a one-off basis (Steam) or as a service (World of Warcraft), especially as both have cracks if I need them. But buying an entire dedicated machine that crippled seems to be a step beyond.
It seems you are implying Sony was not successful. 3 1/2 years unhacked to date, and (likely) at least another 1 year before it is broken.
Have there been absolutely no cheats?
But even if we restrict our discussion to hacking, it's only a matter of time.
You are comparing memory hacks as being equal in measure to exploits. Any online gamer can tell you this is a dishonest comparison at best.
I'm an online gamer, so your assertion is inaccurate at best.
Halo 2 'lag' fix: P2P,
P2P as in, decentralized? That seems like it would worsen the problem and introduce lag issues of its own.
dedicated servers,
Cost money, unless they actually give the dedicated server software to the community.
intelligent server choice
That's what they were attempting to do by measuring connectivity between all players before choosing a server, and it was easily subverted to guarantee that an xbox of your choice was the server every time.
and/or rating.
Well, it's possible to rate someone as a cheater, but it's difficult to prove here. The usual effect would be that you either get a blue screen telling you it's trying to re-establish a connection, or you just feel like there's extreme lag, you suddenly pop back to where you were 20 seconds ago and someone's apparently teleported in out of nowhere and sworded you.
The problem is, actual lag can do that, too.
Beating the aimbots: you're talking about the aimbots from 10 years ago.
2 years ago, if that. I didn't say it was easy, and it wasn't call of duty.
due to erratic client latency and unpredictable nature the server must send opponent movements before seen by the player.
Not necessarily significantly before. Again, it's a simple calculation of whether the player could see that enemy at that point. And if you've got a latency of over 100 ms, I don't think that means your machine needs to be updated that far in the future.
Aimbots: are not and have never been detectable in the hands of a skilled and intelligent player. It has been tried, many times, to no result.
Citation needed, especially as I have seen them be detected.
texture quality is nothing like being able to identify opponents at 2000m because their helmet is suddenly a bright pink color.
Can also be done with server-side mods.
Intelligent hack detection: all of this adds highly measurable CPU load and is only appropriate for dedicated servers, not console hosts.
Worth it, especially given console hosts (not being dedicated) always offer the possibility of even more ludicrous hacks. If you're the server, what's to stop you from suddenly gaining admin-like powers and making people spontaneously explode?
I was (trying) to say that I preferred having a tightly secured blackbox gaming console versus one with open specifications and SDKs and full hardware access. I failed on that point pretty hard. I blame the beer.
Again, it appeared you were trying to say that what you really care about is the cheating, so the reason you like a locked-down console is that there is (you hope) less cheating. Am I right?
Or is there some other reason you like having less control?
Bug/design exploits don't often annoy me much. Usually they aren't too serious and get fixed eventually.
I'm still curious how the one I described was fixed, if it was. The issue is essentially that with a few firewall tricks -- not even rewriting packets, just some very basic rules on which ones are allowed and which ones aren't -- you can force your Xbox to be chosen as the server. Then, just introduce some lag -- it will lag your opponents, not you, so you win. Even without doing it deliberately, being chosen as the server is a decided competitive advantage unless everyone has perfect connections.
There was a point where this particular exploit pretty much dominated who got to any level above around 4 or 5 in Halo 2.
Speed/wall/aim/position/texture/etc. hacks, while some can be prevented by the server, are HUGELY vexing.
Let's see...
Speed can be entirely prevented by the server.
Position can mostly be prevented by the server. Wall hacks, beyond a very close distance, are essentially position hacks. If an enemy is out of sight and out of earshot, there's no reason for the server to show them to you.
Aimbots can usually be detected fairly easily, by being too good. The server can measure, much more accurately than a human, just how accurate they are. There are also other obvious signs which can be spotted by admins and servers alike.
Texture and other similar mods could be problematic -- though the old response was to allow everyone to adjust their settings, so if you really wanted, you could simply turn off HDR/fog/etc and have a significantly uglier game, but maybe a competitive advantage.
Now, combine all of the above. Most of the countermeasures involve server mods or vigilant admins with a stable community, things not really possible on console games.
And it's not an if, it's a when.
Given all that, I'm not willing to bend over for Sony just to protect me from the cheaters. Hell, often, I beat aimbotters and such without cheating -- just straight-out win.
They that would give up essential liberty for a little temporary security...
This whole article is about hacking the PS3. I probably should have used "hackers" though.
That wouldn't make a lot of sense. Your original argument seemed to be claiming that you were talking about the kind of cheating which leads to people winning unfairly at games. That exists with or without control of the machine.
"Cheating" covers more than just exploiting. Hacking, too.
Yes, I realize. My point is only that cheating exists on every platform, inevitably, the end. I'd much rather have a platform that gives me the tools to deal with cheaters than a platform than a platform that locks me down to that extent.
Although it's unfortunate the term hacking was applied to game hacks in the first place.
Slashdot Mirror
A quick glance makes me suspect I'd rather go with IO or self.
But I wasn't looking for a new language, I was looking for a new multi-language VM.
I'm not targeting a big system anyway.
As for tools, smalltalk provides the tools, they are just different than what is used for other languages. The tools for smalltalk (the browser, monticello, the file list etc) work really well for smalltalk.
That's great, but they are also different than the tools for any other language. I want to be able to use my favorite text editor, my favorite version control system, etc.
there is no need for any others - nearly 40 years of development has produced a very efficient and intuitive environment.
And nearly 40 years of development has produced a multitude of general-purpose tools that make me more productive with any language.
In my opinion the only place Java beats Smalltalk
As a language? No contest, you're right.
But with Java, I compile source to bytecode representations, zip those up, and distribute them. With Smalltalk, unless I'm misunderstanding something, I run that program, edit the running program if I want to make a change, and save a bytecode snapshot of a running program, then distribute that -- which seems somewhat cumbersome if someone else wants to import my program into their Smalltalk environment.
I don't get why an object has to care about what class a reference dereferences to, and why methods have to have all that type declaration fluff around them.
I agree completely, which is why I use Ruby when I can.
When I Google that, I find an OS. Fine, but what languages target it?
Python normally caches the compiled bytecode of imported modules in .pyc files and only recompiles them as necessary. It also provides modules for doing this beforehand, which can also be used like programs with python -m, which most distros will do when packages with Python code are installed, because you won't have write access to /usr/lib (or wherever) as a normal user. It is also capable of directly running bytecode even without a corresponding source file.
Sorry, I forgot about that. I suspect it was the GIL that was the deal-breaker here, not to mention the fact that it was tied to a single platform.
I don't know about Perl and Ruby, not being particularly familiar with them, but I wouldn't be surprised if they could do something similar.
They can't. Perl6 will be able to, if it's ever released.
JavaScript can't really be compared to any of the others, as the language doesn't have any standard implementation, de facto or otherwise, and thus one cannot sensibly speak of the features of "its implementation".
Well, we can talk about the fact that Google's v8 (part of Chrome) JIT-compiles to native code, and Firefox and Safari both contain relatively fast Javascript engines which have got to be doing something similar.
You are going to have to provide different packages for all the different platforms you wish to support,
Not necessarily. I suppose it's the case right now that you can't expect users to know what to do if you just give them a jar, but as a contrived example, suppose I distributed a single .deb and a single .rpm. If that contained either source or bytecode, it would work on pretty much all Linux platforms. If it contained machine code, it would be bound to a specific architecture.
using the same binary for all of them really only saves you compilation time,
That can be significant, but the primary motivation here was a new platform which would allow distribution of cross-platform proprietary apps.
The idea was that there are still some apps which don't make sense as web apps (yet) -- my motivation at the time was games -- and if people are going to be building these at all, I'd much rather they be inherently, automatically cross-platform than Windows-only.
Granted, but I was wanting to do game development -- you're going to need a desktop client of some sort. The idea was to have a very small set of native bindings, and have the entire game be portable.
Taken a step further, which I didn't mention (but did consider while evaluating these VMs), I wanted to be able to sandbox a program without losing too much performance. The idea here was to be able to download a game targeting my meta-platform on any platform (Windows, Linux, OS X, consoles) without worrying about security, and to be able to develop such a game without worrying about portability.
If I was going to try that again, I'd probably use WebGL -- but notice, the problem hasn't disappeared, and some new problems have cropped up, like the reluctance of proprietary software developers to allow their source code to be distributed -- they'd be much more comfortable with some sort of bytecode representation.
If Java get closures, what are you missing in Java?
Others have listed other reasons, but let's see...
It's statically typed. Understand, I don't mind strict typing (Ruby is strictly typed), I just get annoyed at having to declare variable types all the time.
The generics is a mess -- as u17 says, it's a hack, and it's also incredibly difficult to understand, and requires a lot of heavy thinking and planning about types and interfaces. Compare to what you get for free from a language like Ruby.
And most of that mess is in the name of backwards compatibility. Excuse me, but do we care that much about backwards compatibility? I suppose it made sense at the time, and I suppose I can't blame them, but it cripples the language today.
Java's threading API sucks. Aside from the overhead u17 pointed out, it's still the same old threading API. Compare to something like Erlang.
Reflection? Easy to use? You've obviously never used a language where it's actually easy to use, like, say, Ruby.
Aside from closures, it's missing Lisp's macros, which take that idea to a whole other level.
And the syntax is brittle -- no operator overloading, for one -- it'd be very difficult to correct any of what I've just said with a library. For example: In most sane languages, a == b has well-defined semantics of comparing the values of a and b. In Java, it compares the values for numerical primitives, and the references for everything else. Because of this, you end up with Object.equals(), which is much more verbose and cumbersome to use, and incurs boxing/unboxing overhead when used with primitives.
Yet despite all that, Java does do some overloading of its own with Strings -- it overloads +, but not ==.
So you can imagine, just about anything interesting I'd want to add to the language, which would be an internal DSL in smarter languages like Ruby and Lisp, would be a mess of verbose library calls in Java.
Similar problems: You can use enumerations and integers for a switch statement, but you can't use strings. Because Java lacks any meaningful way to modify the primitive types, and isn't flexible enough to override case itself, you can't fix this to do what you'd expect, which is for it to use Object.equals(), or even a more verbose version that allows you to pass a Comparator.
What else...
No keyword arguments, and no sane way to add syntax for them. No built-in hash type, and thus no hash literals. Ruby doesn't have keyword arguments either, but its syntax is loose enough that you can use the builtin hashes to replace them.
No symbols/atoms, either.
No good interactive shells. Then again, do you really want an interactive shell in a language that's that friggin verbose?
Hell, verbosity deserves a category of its own. Just look at Hello World in Java. Compare to Hello World in pretty much any other language.
The built-in array type, aside from having an unnecessarily verbose literal, is also a fixed size. I suppose it's useful to have a fixed-size array, but 99% of the time, that's not what you want. Make ArrayList the default array type, have things accept Lists (or better yet, Collections) rather than arrays, and provide syntactic sugar for creating ArrayLists instead of Arrays, then tuck the actual Array type deep in some system library so programmers don't have to bother with it again... but like so many of these problems, you can't actually solve it that way without breaking the language.
Then again, u17 points out a potential problem with that -- ArrayLists, like all Collections, must store objects (and thus references) rather than the actual values. That means ArrayList<Integer> is necessarily slower and bloatier than int[] (by much more than it should be), and there's again nothing you can do about it. Contrast to Ruby -- you'd expect a construct like [1, 2, "three", 4] to be even worse, but it's actually better than an ArrayList of [1,2,3,4] in Java -- I believe it uses a
Is Quake2evolved Java-based?
The nice thing about an assembly language for the web is that it could compile to byte-code run by a standardized virtual machine (which can be further abstracted to be a compatible, thin layer between the language and the processor).
Maybe, but JavaScript is simultaneously a horrible choice for such a language, and an excellent choice for an application development language.
we should have more options than that, especially where other niche languages have an advantage.
Can you give an example?
a language designed for multiple cores/processors
JavaScript can do that now, and it does so with message-passing. Functional languages might be interesting to try that way, but I'm not sure how efficiently they can map to a message-passing system. Erlang, maybe, but it's fundamentally an uglier language than JavaScript -- the good thing about Erlang is the VM.
The latter could be unnecessary if the compiler were advanced enough to support concurrency automatically. I am not a compiler designer,
Neither am I, but I doubt it can be done well.
Actually, CPUs do something like this already, and compilers could, I'm just skeptical about the results. Take a simple for loop iterating over an array and updating each element. How would a compiler be able to infer that to a map function, unless it's hand-optimized for specific types of for loops?
Basically, I think that if we do start talking about an "assembly language for the Web", we should go ahead and try to build one. I wouldn't know where to begin, though, to be honest -- there are two many different models to support. The only real problem I see for Javascript in the near future is multicore, and I think it's manageable, and again, with libraries and frameworks (building on top of Web Workers) rather than with a brand-new language.
Yes, and if the browser doesn't support it, it is a plugin.
All of HTML5 is also a plugin on IE, called Chrome Frame. That's not the relevant issue. The relevant issue is whether it's a standard we can agree on.
Again if Microsoft 'embeds' Silverlight into IE then because it is no longer a plugin and 'it is in line with HTML5 goals'?
They'd also have to irrevocably release all the relevant patents, and there'd still only be the one open source implementation.
There's also no particularly compelling need for Silverlight, when HTML5 presents a much more transparent way to handle video and audio, which is the main reason you'd need Silverlight in the first place.
And according to your definition, Silverlight is also crossplatform, as it runs on...
iPhone is indeed a stretch. OS X and Windows have native implementations from Microsoft, making that about as useful as Flash.
There is thus a total of one open source implementation (Mono), and there's still the issue of patents and of relevance.
HTML5 is trying to break from square box controls and external standards. If of an SVG circle or triangle and text flowing around it, this is the direction not square canvases that use masking tricks to fit on the page in anything but a 'box'.
Then how would you suggest supporting high-performance hardware-accelerated 3D rendering in that environment?
I can think of a few ways to get similar effects, but I don't know that I can think of a use case.
Let me put it another way: <video> is also part of HTML5 and also generally a 'box'. Can you think of how it could be any other way?
You also have the object access level, and WebGL is wrapped in code, you can't reach out and set the transparecy of an 'internal' object being rendered in the scene outside via CSS.
That is a legitimate criticism. I'm not sure there's a good answer, though, especially one that doesn't have serious performance implications.
I don't dislike WebGL, although I would rather put more effort into getting GPU accelerated browsers...
There's still a question of how to render 3D.
Having SVG and other good things of HTML5 and dynamic rendering running on the GPU already then there really isn't a need for WebGL.
That depends what you're doing. Would you really attempt to build a game like Quake that way? Using a 2D SVG, doing all the perspective work and occlusion culling yourself instead of letting OpenGL handle it?
What bothers me about this article and news story is that Google and users are acting like Chrome is rendering Quake in HTML5, which it is not doing, it is only doing the final paint to an HTML5 canvas. This is not a demonstration of HTML5 or Chrome being good at HTML5.
Also fair, it would've been nice if they specified WebGL instead of HTML5, as the way it's worded now suggests WebGL is part of HTML5, which it's not.
I suppose I'm a bit impatient. What bothers me the most about this is that we had the technology to do this in 1999 -- to make something like a web browser that would really be an application-browser -- and I've been waiting a long time to make a truly web-based videogame. This has a shot at it -- if your browser already has WebGL enabled, I could streamline a game to load your starting point within the world in seconds.
I remember taking a long, hard look at the state of various VMs awhile back, and here's what I came up with: .NET isn't a bad design, but it's entirely controlled by Microsoft.
Rotor doesn't change that at all.
Mono changes it a little, but Mono (at least back then) wasn't really a great platform in its own right -- not enough tools, not enough reason to use it, always playing catch-up. Plus, there's the whole patent issue.
On top of all of that, it was never really designed to be cross-platform, and instead seems to be primarily aimed at creating native apps.
The various "scripting" languages have been moving towards VM architectures, and some are quite good, but none that I know of actually feature any kind of ahead-of-time compilation, even to bytecode. That includes Perl, Python, Ruby, JavaScript, and plenty of others.
Lisps are better, but they generally don't compile to an intermediate form -- if they compile at all, it's to something platform-specific, likely machine code.
Smalltalk is interesting, but is even more closed off than Java, and basically requires an entirely different set of tools for working with. It's not really designed to work as a text-based language.
The closest would seem to be Erlang, but it's radically different. While I know of at least one other language trying to target the Erlang VM, it's something that's really designed to work with Erlang. I'm also not entirely sure if the performance is there.
LLVM looks very, very good, but very few languages actually target it, beyond, say, C. It seems to be targeting runtime optimizations, not portability.
I probably looked at a few others I'm forgetting now...
Basically, the top two are still Java and .NET. Both present a VM that supports multiple real languages. In Java, this is by accident, it's hackish, but there are plenty of robust, mature languages other than Java which target it -- Scala, Groovy, Clojure, JRuby... In .NET, this is by design, but the more interesting other languages targeting it seem to be in an alpha state.
So Java is pretty much it. And it means we can take our fun, dynamic languages, and (eventually) compile them to Java bytecode, and create entirely cross-platform apps with no local dependencies other than Java. It means we get much of the work that's been put into optimizing Java for free -- for example, the Java garbage collector. It also means that even when designing a native app, well, Ruby just got threads in 1.9, and there's still a GIL, so no support for multicore. Python has and probably will always have a GIL. JRuby has had real, native Java threads almost as long as it's existed. Ruby has plenty of options for concurrency, but if you want to take advantage of multicore, your options are either JRuby or a unix fork(), and Ruby's GC is not COW-friendly, so fork() is potentially much more expensive than in other languages.
I don't know if Java is the way forward. I hope someone builds something cool on top of LLVM. I certainly hope Java the language dies. But the JVM is about the best we have in terms of open-source, cross-platform, compile-once-run-anywhere VMs.
The dream, from a developer's perspective, is this: In 3-5 years (this is the dream part given how fast the web changes), Javascript is an assembly language.
What? No, you had it right here:
Javascript in isolation is not as bad a language as people make it out to be,
Full stop. In fact, it's quite a pleasant language. The unpleasantness comes from this:
supporting common browsers
And that can be abstracted away with libraries.
What JavaScript needs is libraries, frameworks, and abstraction, not other languages stacked on top of it. More JQuery, Prototype, and SproutCore, and less Google Web Toolkit, Pyjamas, and HotRuby.
and fixing all bugs as you're writing it
I have no idea what you mean here.
I would kill to be able to write an application in Python, C#, or Java and know that I can compile to a package supported by >90% of people on the web.
Well, that's exactly what Google Web Toolkit is, but again, I'd suggest looking into JavaScript libraries instead.
Much like writing in assembly versus higher-level languages, writing Javascript directly will always be faster than compiling from another language. But at what cost to your time and sanity?
Not nearly as much as assembly language.
Again, it's the language. JavaScript is a decent language. Assembly Language... isn't. No matter how many frameworks you pile on top of ASM, it's not going to be pretty until you at least add a hell of a preprocessor, and at some point, we call that preprocessor a "compiler". By contrast, I've written things very quickly in JQuery, kept my sanity, and had it working easily in Chrome, Firefox, and IE, without testing in more than Chrome while developing -- it Just Worked in Firefox and IE. (And Safari, I assume.)
WebGL and other libraries
WebGL isn't a library, it's a binding. It does bind to native OpenGL (if the browser supports that), and while it may not be strictly HTML5, it is in line with the HTML5 goals -- to make the browser itself the platform, without relying on plugins.
If this was an HTML5 demonstration, it would be using PNGs, SVG, and CSS to create the game
Fair enough, though that would be much slower.
Wow, almost as impressive as using activex rendering DirectX content that we first saw in the freaking 1990s.
Yes, because ActiveX is a nice, cross-platform standard with multiple open source implementations... Oh wait.
Read that again until it sinks in, by the way.
Cross-platform -- WebGL runs on Windows, Linux, and OS X, at the very least, and likely on the iPhone. Your attempt to pretend this is a Google-vs-the-world thing falls flat.
Standard -- WebGL is managed by Khronos, who maintains OpenGL itself -- the working group includes Apple, Google, Mozilla, and Opera.
Multiple open-source implementations -- Firefox and Chromium both support it in some dev build or other. That also means Gecko and Webkit, which means dozens of other browsers.
WebGL embedded in a browser or used as a plug-in is NOT the browser's rendering engine doing the work.
So what?
And for what it's worth, it is useful that it ends up on a Canvas. Unless I'm mistaken, that means it is composited with the rest of the document, meaning you could (for example) draw your HUD using standard HTML and only use the GL for the 3D. Please explain why this is a bad thing.
If by XGL you mean modern compositing window managers, they're actually a performance improvement on modern hardware, and some of that "eye candy" is real usability enhancements -- everything from a drop shadow (helps make it more obvious which window is on top, and that it's a discrete window, making it easier to look at and comprehend) to expose or alt+tab with live previews (now which of my many terminals did I want? Hold alt, hit tab, watch them fly by... oh yes, that one)...
Oh, and an actual, working, performant zoom. That alone is worth it.
It's one of those hacks that is cool because it's deeply wrong, not something that is in any way sensible.
Well, yes and no.
Yes, it's deeply wrong, and it's a hack, because we're talking about a Java version of Quake2 which was ported to Google Web Toolkit, and I can't imagine that would lead to the best performance. Also, Quake2 already has a native open source client.
However, running 3D games in the browser is sensible. It's a long way from being a replacement for native games, but think about the appeal of flash games, and add relatively modern graphics capabilities to that.
Or consider an angle for an MMO -- just visit our website and you drop right into the game, no need to download anything, let alone gigabytes and gigabytes of data via BitTorrent. If we change an asset, just rely on standard HTTP cache invalidation to pick it up.
Not hard, if you're willing to go to Quake3 games -- Nexuiz, OpenArena, Tremulous, World of Padman...
The question is whether those can be backported to Quake2.
Hey, why use DirectX when you can just up the hardware reqs and run it in the browser?
*facepalm*
Not that it wouldn't up the hardware reqs, especially with the current state...
But Google is working on a standard for native code in the browser, which would make the browser a safe sandbox for entirely native, full-performance games.
And it is OpenGL. Are you seriously implying DirectX is faster than OpenGL?
And on the other end, are you seriously planning to run a 3D game in a browser on a phone?
Not only am I planning on it, I'm planning for it to work well.
Javascript is, as the name implies, a scripting language.
At the time, that distinction was relevant. It isn't anymore.
it's easy to hack something together, but as the size of the project grows, that same feature makes it harder and harder to keep the whole thing from collapsing into a rats nest lined with spaghetti.
Here we go...
You can write COBOL in any language, and you can write good code in any language. If you don't have the discipline for Javascript, you could always write a preprocessor that forces it on you, but I think you'll find that knowledgeable programmers using it on real projects don't tend to have these problems.
The awful fact is that most programmers are mediocre and need handholding from the language to produce good or even okay code.
Another fact is that this same handholding slows down good programmers until you only have mediocrity everywhere. I don't think it even succeeds in making bad programmers mediocre, as TheDailyWTF will confirm.
A good programmer in a good language can easily outperform ten bad-to-mediocre programmers in a crippled language.
Languages like Javascript or Python allow - even encourage - sloppiness, since that facilitates writing quick and dirty scripts,
or Ruby, I would guess. Yet the Ruby community seems to enforce readable, well-architected code, along with readable unit tests (specs) for every change. Say what you will about the effectiveness of testing, it sure as hell isn't sloppy, or a "quick and dirty" solution.
Do I use languages like that when I need a quick hack? Sure! That's because they're good languages, so a quick hack is going to be easier to develop in Python or Ruby than it is in C. But you can write quick hacks in C, Java, or anything else, and you can also write solid code in Python, Ruby, and even Javascript.
It doesn't exactly help that scripting languages tend to catch most errors at runtime rather than compile time,
It doesn't hurt as much as you might imagine when you have full test coverage. In fact, given full test coverage, runtime errors are compile-time errors, meaning fewer runtime errors slipping by than you'd have with a program written in a stricter language but with fewer tests.
mostly because they like to pretend that variables are untyped
That's not pretending. In languages like Javascript, the variables are. It's the objects that are typed.
yet fail if you try to do something the object doesn't support.
Duh. What did you expect?
Here's a hint: Even in Java, there are many cases where something will fail at runtime when you try to do something the object doesn't support, faster than you can say NullPointerException. Or take the standard libraries -- fail-fast iterators, plenty of stuff not designed to work well with concurrent access from multiple threads...
You seem to be assuming that we all write crazy code where no one knows what type of object we're dealing with. In practice, it's not that far off from anonymous subclasses in Java, and it's significantly faster to write, read, and reason about when we don't have to write LongClassName<OtherLongClassName<OtherReallyLongClassName>> foo = new LongClassName<OtherLongClassName<OtherReallyLongClassName>>();
Ever tried to wrap your head around Java Generics, or C++ templates, or .NET... I'm guessing generics? It starts out innocently enough, but it eventually leads to serious issues, some even cropping up at runtime, plenty leaving you scratching your head trying to figure out how to describe exactly what kind of type makes sense here, what kind of inheritance relationship, etc...
That whole nightmare goes away when you can simply declare a variable with 'var' and let the system figure it out.
Several possibilities there:
Of course homeopathy won't help with serious illness, but most illnesses are not serious, and will pass by on their own. In such case, a placebo to alleviate the symptoms - or, rather, how the patient experiences the symptoms - can be the best possible help.
Perhaps, but I don't think that justifies deliberately deceiving the general public, nor spending tax dollars on what is quite literally making people feel better.
It's not bending over for Sony if you bought it for what it was designed for: gaming.
It's gaming on their terms, with (apparently) their ability to revoke anything at any time.
I don't mind that on a one-off basis (Steam) or as a service (World of Warcraft), especially as both have cracks if I need them. But buying an entire dedicated machine that crippled seems to be a step beyond.
It seems you are implying Sony was not successful. 3 1/2 years unhacked to date, and (likely) at least another 1 year before it is broken.
Have there been absolutely no cheats?
But even if we restrict our discussion to hacking, it's only a matter of time.
You are comparing memory hacks as being equal in measure to exploits. Any online gamer can tell you this is a dishonest comparison at best.
I'm an online gamer, so your assertion is inaccurate at best.
Halo 2 'lag' fix: P2P,
P2P as in, decentralized? That seems like it would worsen the problem and introduce lag issues of its own.
dedicated servers,
Cost money, unless they actually give the dedicated server software to the community.
intelligent server choice
That's what they were attempting to do by measuring connectivity between all players before choosing a server, and it was easily subverted to guarantee that an xbox of your choice was the server every time.
and/or rating.
Well, it's possible to rate someone as a cheater, but it's difficult to prove here. The usual effect would be that you either get a blue screen telling you it's trying to re-establish a connection, or you just feel like there's extreme lag, you suddenly pop back to where you were 20 seconds ago and someone's apparently teleported in out of nowhere and sworded you.
The problem is, actual lag can do that, too.
Beating the aimbots: you're talking about the aimbots from 10 years ago.
2 years ago, if that. I didn't say it was easy, and it wasn't call of duty.
due to erratic client latency and unpredictable nature the server must send opponent movements before seen by the player.
Not necessarily significantly before. Again, it's a simple calculation of whether the player could see that enemy at that point. And if you've got a latency of over 100 ms, I don't think that means your machine needs to be updated that far in the future.
Aimbots: are not and have never been detectable in the hands of a skilled and intelligent player. It has been tried, many times, to no result.
Citation needed, especially as I have seen them be detected.
texture quality is nothing like being able to identify opponents at 2000m because their helmet is suddenly a bright pink color.
Can also be done with server-side mods.
Intelligent hack detection: all of this adds highly measurable CPU load and is only appropriate for dedicated servers, not console hosts.
Worth it, especially given console hosts (not being dedicated) always offer the possibility of even more ludicrous hacks. If you're the server, what's to stop you from suddenly gaining admin-like powers and making people spontaneously explode?
Citation?
What I found, the last time I looked, is that it keeps a local whitelist, and sends URLs not on that whitelist to the server-side blacklist.
There are legitimate reasons for keeping the blacklist server-side, but it does have pretty much the same privacy issues.
I was (trying) to say that I preferred having a tightly secured blackbox gaming console versus one with open specifications and SDKs and full hardware access. I failed on that point pretty hard. I blame the beer.
Again, it appeared you were trying to say that what you really care about is the cheating, so the reason you like a locked-down console is that there is (you hope) less cheating. Am I right?
Or is there some other reason you like having less control?
Bug/design exploits don't often annoy me much. Usually they aren't too serious and get fixed eventually.
I'm still curious how the one I described was fixed, if it was. The issue is essentially that with a few firewall tricks -- not even rewriting packets, just some very basic rules on which ones are allowed and which ones aren't -- you can force your Xbox to be chosen as the server. Then, just introduce some lag -- it will lag your opponents, not you, so you win. Even without doing it deliberately, being chosen as the server is a decided competitive advantage unless everyone has perfect connections.
There was a point where this particular exploit pretty much dominated who got to any level above around 4 or 5 in Halo 2.
Speed/wall/aim/position/texture/etc. hacks, while some can be prevented by the server, are HUGELY vexing.
Let's see...
Speed can be entirely prevented by the server.
Position can mostly be prevented by the server. Wall hacks, beyond a very close distance, are essentially position hacks. If an enemy is out of sight and out of earshot, there's no reason for the server to show them to you.
Aimbots can usually be detected fairly easily, by being too good. The server can measure, much more accurately than a human, just how accurate they are. There are also other obvious signs which can be spotted by admins and servers alike.
Texture and other similar mods could be problematic -- though the old response was to allow everyone to adjust their settings, so if you really wanted, you could simply turn off HDR/fog/etc and have a significantly uglier game, but maybe a competitive advantage.
Now, combine all of the above. Most of the countermeasures involve server mods or vigilant admins with a stable community, things not really possible on console games.
And it's not an if, it's a when.
Given all that, I'm not willing to bend over for Sony just to protect me from the cheaters. Hell, often, I beat aimbotters and such without cheating -- just straight-out win.
They that would give up essential liberty for a little temporary security...
Nope, it sends them to Google...
Oh, I see. In the search box. Apparently the Awesome Bar doesn't do search suggestions.
This whole article is about hacking the PS3. I probably should have used "hackers" though.
That wouldn't make a lot of sense. Your original argument seemed to be claiming that you were talking about the kind of cheating which leads to people winning unfairly at games. That exists with or without control of the machine.
"Cheating" covers more than just exploiting. Hacking, too.
Yes, I realize. My point is only that cheating exists on every platform, inevitably, the end. I'd much rather have a platform that gives me the tools to deal with cheaters than a platform than a platform that locks me down to that extent.
Although it's unfortunate the term hacking was applied to game hacks in the first place.
Agreed.