All the additional complications of a car are because you want to drive from A to B yourself. Plus quite a lot of the controls have nothing to do with driving, they're for the stereo or the AC or they serve secondary purposes such as the gas gauge or the maintainance lamp.
And this maps well to computers.
The additional complication of having to change the oil occasionally (or have someone else do it), knowing what the RPM gauge means (or at least that redlining is bad), needing a key to get into your car, etc, all have reasonable analogies in the computer world, and there doesn't seem to be much in a computer that doesn't have a similar analogy in the car interface.
The additional stuff, like the stereo, air conditioning, windows, etc, maps to additional stuff users might have running in the background (music, an IM client, etc).
There's an analog to a taxi, too, at least for some things -- you can ask a librarian for help looking something up. I can see where you also might compare a kiosk (or something similarly kiosk-ified, like an iPad) to a taxi.
But that's a difference in quantity, not in quality.
It absolutely is a difference in quality -- there is a test at the end.
I realize the attitude may be the same -- just learn enough to get on the road and from point A to point B. The approach is quite different, though -- you're going to learn everything in the curriculum, you're going to be tested, and you'd better be able to demonstrate some level of competence before we're going to let you out there.
the vast majority of people have no emotional connection with their computer at all. It's just a thing.
I realize this. I feel no particular attachment to my car, either, though I realize some people do.
But I have that bare minimum of understanding of how it actually works, and how it should be used. I know that it burns gas, that it needs oil to keep the engine from melting... I wince when I drive too fast over a pothole, knowing it can't be good for the shocks. That's both knowledge and intuition that's missing here.
Really? Let me see... there is no solution to indicating the sender of a message better than believing the "From:"? We've not invented cryptographic signatures, I assume.
No one wants to use PGP, and only the truly hardcore security geeks are ever at keysigning parties. The trouble here is the concept, not the UI -- most people really do seem to find it difficult to wrap their heads around a web of trust.
S/MIME might be better, and I have to admit I have less experience with it -- it seems to be an individual, per-user cost, and requires the user to keep track of a private key, making things like webmail difficult. It's also at least one central, controlling authority of email. To do this right is a UI, technical, political, and educational challenge.
It also complicates one possible response to spam -- different email addresses for different uses -- because email addresses suddenly cost much more.
Add to this the fact that so few emails are sent with any signatures at all, and there's no way that I can assume a message is not genuine merely because it lacks a signature, even if it's from a user who frequently signs their mail.
even Windows has a fine-grained security policy these days. Except that there is absolutely no useability in it, none whatsoever. Even if you're an expert, it's hidden away deeply.
I do agree with this. I've actually noticed it for awhile -- I do it somewhat haphazardly myself, but there really does need to be a better way to instantly spawn new users (or at least contexts) for new applications.
To be fair, we do have a platform which does this automatically -- the Web. And many native applications would need to be changed to work with greatly reduced privileges, especially to be usable in that case -- many programs, I w
A light switch works so well precisely because it gives you two options: "Lights on" or "Lights off", instead of presenting you with a spectrum of things you can do with electron flow through a wire.
Mostly because, in that situation, it would be useless.
By contrast, despite being automatic, my car's transmission also has a first and second gear and an overdrive toggle, not to mention neutral and reverse. That's just the transmission -- my car also has four separate braking mechanisms, each with their own unique interface. It may be possible to simplify this, but people are willing to put up with this situation from a car.
Take a moment to look into a car sometime. Count how many separate controls there are, and remind yourself that this thing's purpose is ultimately to move you from point A to point B.
As Einstein said: Make things as simple as possible, but no simpler.
Sure, some Apps would not be accepted in the App Store, but I can still put them on my own devices, no problem at all.
Define "no problem at all" -- as I understand it, you're describing a scenario which either requires a jailbroken phone or a dev kit.
The difference really isn't that massive. For the user, light switch, coffee machine, car, computer - all just tools to enable him to do what he wants to do. Sure, some of those tools have multiple functions, and computers probably the most. But still a tool.
I'm sure even our hypothetical user can tell the difference between a coffee machine, which takes perhaps two minutes of instruction (if that) on how not to get burned, and a car, which in many places takes several months of training before you're legally allowed to drive on public roads.
A few years ago, a magazine did a test on phishing, giving well-made phishing mails to both novice users and security experts to let them say whether they think they're genuine or phishing. Turns out, the statistical difference between the two groups was not so high.
So, which magazine, what was the threshold of "security expert", and what was the proposed action? I might say that an email looks legitimate, and still not click anything inside it.
The main problem with phishing is that most of our e-mail programs seem to be designed to make phishing easy and noticing the details you need to notice to make the distinction as hard as possible. Almost all the information that is available that makes it possible to discern a phishing mail is hidden away somewhere. Meanwhile, all the information that triggers your mind that you need to react on this important mail - i.e. click on something - is large, in-your-face, middle-of-the-screen.
This is what a naively "simple" design would call for. I can certainly look at headers (or the raw message) when I suspect something, but when I leave it on, it's annoyingly difficult to get through normal email -- users wouldn't have a chance. If we make it harder to click on things, we penalize people sharing links instead of pasting the entire article into the body of an email, among other things like registration links and such.
So you simplify it -- make everything open when you click it, and hide away the scary headers so people don't have to learn about them. Until they do anyway, because they need to be able to check whether a message is forged.
More importantly, simply clicking a link from a phishing email isn't likely to cause harm unless you also fall for the site it's linked to. I haven't seen a proposal for any way to make this better which doesn't come with significant drawbacks -- and here, the information is "hidden away" in the URL bar.
That's nonsense. Where do you have any evidence for that claim?
Which one? That the only way around is a whitelist, or that Apple and China seem to want whitelists?
I'm an iPhone developer. There is no "dumbing down" here at all.
For the user?
Anything I want it to do, I can make it do.
Jailbroken?
the user has most of the complicated stuff hidden away from him.
In the case of the iPhone, it's not that the complicated stuff is hidden. It's that it's actually forbidden -- see above. Can you make it do anything Apple doesn't explicitly allow?
That is not a conspiracy,
I never suggested it was.
Nor do I think Apple and China are in a conspiracy to censor technology -- they just seem to agree (quite publicly and openly) that computer users need to be protected from themselves, beyond the point of making it simpler and more usable, and to the point of removing choices.
Look at cars: Early on, you'd better know quite a bit about it, just to drive one. These days, you put your car into the ignition, and you care nothing about what goes on under the hood.
I do, however, care that the hood is not welded shut. I care that like most drivers, I also know how to change a tire and jump a car -- and jumping a car is something that it's useful to be able to do once in awhile.
Do you know how to make fire without matches?
No. However, I do know how to properly use matches. I know that even when a match is out, I shouldn't immediately put it on something flammable.
How to milk a cow?
No, but I know not to drink spoiled milk. Do you see where this is going?
I'm a technophile, I'm hardly a Luddite. I do appreciate things getting easier, and I said so. But there is a limit to how much I can avoid learning because of technology. Safety matches are better than normal matches, but you can still (easily!) burn yourself.
What you need to do is teach them which tasks require elevated priviledges and to become suspicious when something else, such as their mail program, suddenly has a red border.
Then they will come to me every time they see that, and when I get sick of it, maybe they'll believe the email that says "Don't be alarmed when Outlook's border turns red, this is part of a normal email virus scan."
In this case, the basic principle is applicable to more than just this one thing (window borders), and is also not terribly complex. In particular, understanding the concept of trust will also help them understand what those scary certificate warnings are actually asking, why they shouldn't download random crap, why they should lock their computer when they're away from their desk, and so on.
And it takes on the order of ten minutes to explain to an intelligent (but nontechnical) person. I speak from experience here.
the better support your tools give, the less education you need.
I'm not sure that's true. Hopefully less rote learning, sure -- I know dozens of commands by heart, and whenever I need to teach even one to a novice user, I consider that a failure.
But the fundamental concepts haven't changed much, and can't be made much simpler without removing a crucial bit of understanding. Teach the underlying principles, and all the specific rules ("Only these three programs should ever be red!") become intuitively obvious.
I also insist that there is far more idiot-proofing possible than we tend to think. If you study design for a bit (not the computer stuff, the real-world stuff about light switches, doors, coffee machines, etc.) you are quickly surprised at how much a good design can solve. Our computer interfaces are worlds away from that at this time.
A light switch controls one or more light sources. At the very best, it can control brightness on a scale (a dimmer) rather than a simple boolean on or off.
Doors are open, closed, or revolving. Some automatically open and
It's not about memorizing facts, or about recalling something, it's about knowing what you know and what you don't know. I don't know how to use a chainsaw properly, but I know enough to know that I don't know, and that I would need to learn how or I'm going to get hurt.
If it is easier to simply design in a safety than to educate everyone and keep them educated, then building in the safety is the proper thing to do.
That's true, if the safety has no downsides whatsoever. Otherwise, it bears more discussion.
For example, the iPhone and the Great Firewall of China, both of which claim to be making things more secure and stable for you by removing your choice. Even if the iPhone is more secure for the kind of user who would download BonziBuddy, I don't think it's worth it, and this is exactly what is meant by dumbing down. Compare that to your idea:
I still don't understand why current operating systems don't indicate the priviledge level an application is running at by, say, a coloured border. You'd still need to educate people on what it means, but a fairly simple safety gives them a lot more options than the stupid "well, you could open a console and run ps" geek solution.
But for this to work, you need to educate people on a hell of a lot more than "Here's a colored border." You need to educate them on what privilege separation means, why they might trust or not trust a given program, why they should trust things as little as possible, etc.
It requires fundamental education, much like you'd get from driver's education, to be truly useful. Yes, we should include antilock brakes, but those cannot be a substitute for knowing something about hydroplaning and ice.
You don't need to know how to change your oil -- you can pay someone else to do that. You don't even need to know how often to pay someone else to change your oil. You just need to know that cars occasionally need maintenance, and that before buying a car, you should learn what you need to know to maintain it.
To bring it back to the original "fire" example: If there are no disadvantages, we should make it so no one wants to look into their gas tank with a lighter. But there's a limit to how much idiot-proofing you can do. If you don't teach people that fire and gasoline don't mix, or about flammability in general, stupidity will find a way.
DVD has a capacity of 10 mbits. Blu-Ray has around 50 or 60.
And that's just a single video stream. Now imagine a household with more than one person wanting to use it...
Now, granted, everything probably will be compressed to hell, because at this point, it's no longer your ISP that's the bottleneck, it's theirs. There's also a lowest-common denominator factor -- content will be made to serve those at 1 mbit, not those at 100.
Still, asking why you need that is a bit like asking why you need any technological upgrade. You don't, yet, but if it's there, someone will find a use for it.
They are not, however, necessary in their current form. At a bare minimum, you no longer need a three to six lane highway to handle people, just one lane for freight and utility.
As long as we're going nuts, there are ideas for how to handle package delivery. I don't know how practical a pneumatic tube system would be, but it's an idea.
I haven't bought a single Sony or Apple product lately. I still use the Apple keyboards I have, but when that wears out, I'll definitely be looking for something else to replace it with.
But you're right, it does seem people in general have done this.
On the other hand, Xbox 360 doesn't limit disc games to one user account nor require periodic Internet activation to play offline.
Fair enough -- but that's disc games.
I guess the lesson is that if I mostly bought physical games, or rented them, I'd use a console. For downloading games, I'll use Steam or find things DRM-free.
Ping times.
I honestly don't get it.
I've played Halo over the Internet. I've played Counter-Strike over the Internet. I've played Quake 3 over the Internet. All of these are fast-paced action games, and all of them are perfectly playable.
I've played it against people on all sorts of ISPs, and certainly, anyone close enough to be coming to my house to play is going to have a decent ping time. I've also played it against people in other cities -- bring up a server list, sorted by ping time by default, or let Xbox Live match me against someone decently close.
Is Smash Bros actually faster than these other games, somehow? Or did Nintendo manage to screw up multiplayer?
I'm glad not everyone on Slashdot buys into the common assumption that kids don't matter.
It's not kids necessarily here, it's that there are other priorities to spend money on than games.
You might be thinking of the "think of the children" meme, which is about something else entirely. It's not that children don't matter, it's that they're often brought up as a purely emotional argument, even a red herring -- for example, it's reasonable to think of the children and then restrict the sale of certain games to minors. It's not reasonable to think of the children and then try to ban certain games from distribution to anyone.
Macs don't restrict what software you can install on them, other than by not being Windows. Anything you can port, you can run, unrestricted. This is not the case with consoles or iDevices.
for real, you are asking me 'so what' and that's your argument?
I'm sorry, I could've been more specific:
- Why is it important not to call the server as often, especially when HTTP caches will do the work for you?
- Why are you comparing a complex Java app (or applet) with a "simple" HTML design?
- What does "large" amounts of data have to do with it?
Some of my users think that their 'computer is broken' when somebody re-sizes a window on their desktop,
If your argument is that Java is a better environment for dealing with this particular class of users, I guess you win. That sounds like the same class of users who got bent out of shape when I attempted to migrate them from Outlook to Thunderbird, and Thunderbird didn't have their emails colored the way Outlook did. Seriously, they categorized emails by color.
Those users are a lost cause for doing anything really interesting. There's a pervasive attitude in the non-IT world that even people who sit in front of a computer their entire day, whose entire job entails working with a computer, should somehow not have to be computer-literate, that it should be someone else's job to install antivirus, update their computer, keep it clean, and filter their Internet so they can't screw it up.
I think the Web can do this, if not now, then soon. But I also think that recreating an existing app for such users isn't really an example of "new development" that the AC was talking about.
Rendering done by the Java applet is completely different from what a browser does.
I'm sure it is.
Browser needs to parse HTML out, it needs to create some form of a document (DOM) it needs to prepare for quirks...
So if you've got a fully compliant page (thus, you don't trigger quirksmode), you don't use InnerHTML, and you do create and update the table with JavaScript, you're not always triggering every stage of that, or even most of those stages. You can even avoid reflows.
Java applet has none of those issues, it does not need to parse out any documents,
Other than the document containing the Java applet, and you'll need to parse something to get at the data.
as a result it responds immediately. 1 second after I load the 20,000 rows into it I can scroll ALL THE WAY TO THE BOTTOM. At this point a browser rendered maybe 300-400 rows only...
...if you rendered it as a simple HTML table. I'm fairly confident I can match what you've just described.
Now, you're claiming that you can just render a 20k row table in Java, but what is that "rendering" actually doing? Do you have a pixmap of the entire table in memory? Or are you loading it into some Java library's concept of a "table", which draws only the relevant bits on the screen?
But that's exactly the point -- I can draw only the relevant bits on the screen with a Javascript app. It may take a library to do it, but it takes a library for you to do the same thing.
- for a compiled language it is not that much more verbose than C or C++, in fact less so depending on what you are doing.
Define "compiled language" -- that's an implementation detail. Lisp is a compiled language.
you have no idea what you are talking about. GWT is not a library.
Why is this important?
if GWT was written in C or C++ or PHP or whatever it still would have been as bad in terms of amount of code as GWT is with Java right now, not because of Java but because of what GWT is doing. GWT architecture requires much more code to be written that will have to be translated into Javascript/HTML
It may be an issue with the architecture of GWT, but I don't see how it's at all related to any particular badness in HTML.
Having the same hardware doesn't make it a PC. Being able to mod it and run it on a general-purpose computer, with a general-purpose OS, is what makes it a PC.
At least console DRM allows lending game discs to friends and resale to GameStop or to eBay buyers,
That's the single killer feature of console games, and something I wish Steam would implement. The closest it has is, if you somehow end up with an extra license (due to, say, buying two bundles with overlap) you can give a copy away.
As with WiiWare and Xbox Live Arcade.
Do either of those allow re-downloading those games (for free) on a new console? With Steam, all I need is a username and password.
most Steam games need four PCs and four copies of the game for four players.
True, but deals can be had to make that less painful, and there are genres for which single screen really doesn't work well. Halo comes to mind -- as much fun as it might be to have the option, if I have four friends (and if money wasn't a factor), I'd rather have four networked Xboxes than one.
Look at Stardock's Impulse, or Penny Arcade's Greenhouse.
Now, it may be the case that such a system can't be successful, but there's nothing stopping anyone from doing digital distribution without DRM -- in fact, it's much easier to do so. It's just that Steam's DRM is what many people (myself included) consider to be a fair trade.
There is a version of the GPL which specifically addresses this. It's a loophole in the spirit of the GPL, though not the letter, just like Tivoization.
Yeah, I know, we've seen Scala and Clojure, but they're rather shitty and impractical for large-scale real-world software development.
Be specific. How are they impractical? In particular:
Clojure is just a reimplementation of one of the oldest programming languages around, Lisp.
And what's impractical about Lisp, particularly a Lisp with STM?
It's also funny that you mention this:
Sun's lack of vision over the past decade has rendered Java far behind languages like C#, Python, Ruby, and even Perl.
Here's the thing: For awhile, JRuby was faster than MRI, the main interpreter. YARV, the new MRI, is faster still, but JRuby seems to be catching up. And JRuby can do real threads, without a GIL, something MRI can't or won't. It runs all sorts of stuff Ruby people expect, including Rails. There are even a few examples of Java libraries which had Ruby equivalents, but the Java versions are the only ones still maintained -- for example, DataMapper supports Oracle just fine, but the only current low-level Oracle adapter that's supported is the JDBC one.
Then there are the crazier things, like running Rails on Google App Engine. I don't necessarily like the JVM, but it does mean I can run any language I like so long as it fits into that Java container.
I'm not sure how close Jython is to that kind of status, but I've been forced to develop stuff which runs on Oracle's WebLogic, and, surprisingly, the WebLogic Scripting Tool is written in Python, and runs on Jython.
It's also funny you mention Perl. What's the #1 reason for using Perl? CPAN. There's tons of Java libraries out there, though not as nicely organized as CPAN last I checked. If I were to take one such library -- say, a nice, well-behaved, self-contained jar -- I could use it trivially from my Ruby app. The Perl concept of grabbing existing CPAN libraries, maybe some only thin wrappers around C libraries, and binding them together with a thin bit of scripting glue to make something cool, is definitely alive and well here -- except you don't have to write any glue, it's trivial to just use the Java APIs.
So, I hate Java as a language. There are languages I merely dislike, or prefer not to use, like Python or Erlang, but I actually hate Java. But the JVM looks like it's turning into something cool.
The JVM is an absolute mess compared to.NET, of all things.
Except that.NET really isn't even to the point the JVM is for "write once, run anywhere." The main implementation is Microsoft's, and Mono is always two or three steps behind. You can either write stuff using Microsoft's APIs and hope Mono keeps up -- which would be like declaring your Windows app is "cross-platform" because it runs under Wine -- or you can stick to purely Mono stuff, which means you'll have to distribute native libraries (like GTK) with your app.
I think I've given up looking for the perfect VM. I'm sure the JVM isn't it yet, and I would guess that some other VM will take over. After all, the JVM physically can't (and may never be able to, may never want to) do some of the tricks the Erlang VM does.
But you're writing Scala and Clojure off as "shitty" without giving a real reason why, and you're either claiming people aren't using Java (or the JVM) for new development, or saying they're stupid for doing so. Where you're not factually wrong, you're just spouting opinions without backing them up.
If you're the same AC, that's a remarkable change of position -- you seemed to be claiming that Java wasn't seeing new development, and now you're claiming that it is, and it's just stupid.
Java in a browser is a much better environment for desktop like applications that need to handle large amounts of data without constantly calling the server than a simple HTML design that requires the browser to render all of that data.
So what?
An HTML page with a table that has 20,000 lines with 8 columns takes just under a minute to render (depends on a machine, but it's a good estimate) and it only takes a second (or less) to render in a Java applet with the same table.
And I bet a Java applet which attempted to render 20,000 lines all at once would perform just as poorly. It really wouldn't take much JavaScript to replicate what Java is probably doing here -- render only the rows which are actually visible, and cache the rest in RAM.
Your mention of "constantly calling the server" suggests that would be a bad thing, too. The browser's HTTP cache works with XHR, so I really don't get where that's an issue unless you need the data to be downloaded all at once.
hundreds of times easier to do in a Java applet than in HTML, never-mind gwt or any other help you can get from any libraries, Java+Swing is still easier to write than anything in GWT
And did you try anything other than GWT? Certainly, if you're going to claim this:
it takes much less code to get the same functionality as well.
Java, as a language, is verbose as hell, so I would guess that a Java library that outputs HTML is worse than a Java library that talks directly to a graphics system. But those aren't your only choices -- JavaScript is decent, and has its own libraries.
You're also assuming that the functionality you get from Java is worth the functionality you lose. You're now requiring people to download a plugin -- no, not everyone has Java already, certainly not a recent version -- and your app is now rendered as an opaque blob, which means users can't script it with greasemonkey, it doesn't work with back/forward or bookmarking, it can't easily interact with other things on the page that want to behave like a webpage... Believe it or not, there are places where the Web beats a desktop app.
You may be able to replicate that native web feel, but that's going to take a hell of a lot more code than it'll take me to develop a decent native web-based app.
I'm not saying I agree with AC, but I really don't see much of a reason for doing browser-based Java -- though I do use it on the server side for other things.
But he's also still trying to get the last word in, claiming 'I still don't think they're art, I just don't want to discuss it'
I don't know that he's even doing that. I suppose this part you mentioned...
I had to be prepared to agree that gamers can have an experience that, for them, is Art
But see, art is subjective. Many of us tried to make that point. I don't have a problem with this statement unless he's outright saying they're wrong.
He never said once, in this entire article, that he was right and that videogames are not art. In fact, the tone of the entire article is, "I may well be wrong about this, and I was certainly wrong to pretend to have a valid opinion in the first place."
He's being skeptical, which is fair. But he's also being honest. Read the next few sentences:
I don't know what they can learn about another human being that way, no matter how much they learn about Human Nature. I don't know if they can be inspired to transcend themselves.
Note: "I don't know." And then he continues:
Perhaps they can. How can I say?
There it is. That's exactly what I wanted to hear out of him. I can't ask for more, so long as this is the case:
I may be wrong. but if I'm not willing to play a video game to find that out, I should say so.
My guess is that this actually does curb piracy, but it does so without violating net neutrality or hampering legitimate, educational uses. More importantly, that system probably costs them way less to set up and maintain than anything pro-active, as it still lets the MPAA do the heavy-lifting. I assume they'd just pass any letters from the MPAA (including legal action) straight on to me, thus meaning they have no legal liability one way or the other.
This would reverse all of that. It'd make the school responsible for policing what students are doing on the school network, and thus, the school would be responsible if they aren't effective. In fact, it seems to be operating under the assumption that this is already happening. The University of Iowa, I'm told, functions this way, but any university which does anything to hinder piracy is not doing themselves any favors.
On a console, I prefer a physical disc, because at least that way, if I lose/break the console, I don't lose ALL my games.
With Steam, or anything similar, or anything actually DRM-free, I would much rather have a digital download. It's far more convenient, so long as I can actually, legitimately, easily make backups -- or, in the case of Steam, Valve has it backed up for me.
He's saying something much more honest, insightful, and true than he's getting credit for.
He seems to be saying that he not only could be wrong, but that he really isn't qualified to comment. He's admitting that he's not willing to get the required experience (play enough games) to be able to comment and be taken seriously. Given these two things, he's bowing out.
Now, it does seem like it took a lot to get it here. It seems he's acknowledging that he was "bull-headed" and that he's mostly writing this because of the barrage of criticism he's received. But what he's actually said is right on -- he isn't qualified to comment, and if he really wants to, he'd have to both solidly define art and play some games, which he's not prepared to do.
I don't have a problem with "backpedaling". I don't like that it took him this long, and I do wish he was a bit more explicit and humble in his wording. But he's realized exactly what he should have, given his experience, and he's said so. I wouldn't expect more.
It's not a good comparison to compare a language to a framework, and attacking the language for the lack of a framework,
The problem is, once you add a framework, PHP loses every last advantage it had over a real language. It becomes bigger and slower (so, may as well use Rails), and it's no longer something that everyone just knows with no training (so, may as well use Rails).
PHP is not inherently unmaintainable,
To the extent that a language can be unmaintainable without trying, I think PHP is about the worst out there. I'd again draw an analogy to C -- you can make a good Web framework in C, and you can write good, maintainable web apps in C. But why would you ever want to, when you have better options?
security issues with PHP apps has nothing to do with the language, but lack of programmer skill.
mysql_real_escape_string() wants a word with you. Yes, you can abstract away the shit that is the basic language, but you can do that in any language.
no framework spaghetti relying on globals
Do you know why the legacy code is written that way? Last I checked, PHP still didn't have properly scoped variables. Your choices were global, function, and, more recently, instance. Contrast to a decent language, like, say, JavaScript, which supports proper local variables.
I mean, objects were tacked on in what, version 5? So it's hardly a surprise that you've got piles of non-OO code -- but PHP doesn't have any of the tools you could use to build proper OO, like real first-class function pointers (or references, or closures, or anything like that), so basically, if you wanted any concept of state that you didn't pass around from method to method, you needed globals or the database.
And the database was a mess. How recently were actual parameterized queries added, so we can stop doing mysql_really_escape_everything_magically_i_mean_it_this_time_plz()?
Why a lot of PHP is such a garbled mess then? Low barrier of entry, a lot of complete newbs has been using PHP as their first touch to anything programming.
Same with Rails, but it's not nearly as much of a mess.
Just count how many language side security flaws PHP has nowadays... Right at about 0.
Is that uncommon? I bet gcc doesn't have many segfaults, either, but that doesn't mean C is a good language to use if you don't like segfaults.
Go with experienced developers, who actually think and know what they are doing, and not the novices who don't know what they are doing.
That's true regardless of the language. But while you're at it, why not give those experienced developers a tool that actually helps them, rather than getting in their way?
Slashdot Mirror
All the additional complications of a car are because you want to drive from A to B yourself. Plus quite a lot of the controls have nothing to do with driving, they're for the stereo or the AC or they serve secondary purposes such as the gas gauge or the maintainance lamp.
And this maps well to computers.
The additional complication of having to change the oil occasionally (or have someone else do it), knowing what the RPM gauge means (or at least that redlining is bad), needing a key to get into your car, etc, all have reasonable analogies in the computer world, and there doesn't seem to be much in a computer that doesn't have a similar analogy in the car interface.
The additional stuff, like the stereo, air conditioning, windows, etc, maps to additional stuff users might have running in the background (music, an IM client, etc).
There's an analog to a taxi, too, at least for some things -- you can ask a librarian for help looking something up. I can see where you also might compare a kiosk (or something similarly kiosk-ified, like an iPad) to a taxi.
But that's a difference in quantity, not in quality.
It absolutely is a difference in quality -- there is a test at the end.
I realize the attitude may be the same -- just learn enough to get on the road and from point A to point B. The approach is quite different, though -- you're going to learn everything in the curriculum, you're going to be tested, and you'd better be able to demonstrate some level of competence before we're going to let you out there.
the vast majority of people have no emotional connection with their computer at all. It's just a thing.
I realize this. I feel no particular attachment to my car, either, though I realize some people do.
But I have that bare minimum of understanding of how it actually works, and how it should be used. I know that it burns gas, that it needs oil to keep the engine from melting... I wince when I drive too fast over a pothole, knowing it can't be good for the shocks. That's both knowledge and intuition that's missing here.
Really? Let me see... there is no solution to indicating the sender of a message better than believing the "From:"? We've not invented cryptographic signatures, I assume.
No one wants to use PGP, and only the truly hardcore security geeks are ever at keysigning parties. The trouble here is the concept, not the UI -- most people really do seem to find it difficult to wrap their heads around a web of trust.
S/MIME might be better, and I have to admit I have less experience with it -- it seems to be an individual, per-user cost, and requires the user to keep track of a private key, making things like webmail difficult. It's also at least one central, controlling authority of email. To do this right is a UI, technical, political, and educational challenge.
It also complicates one possible response to spam -- different email addresses for different uses -- because email addresses suddenly cost much more.
Add to this the fact that so few emails are sent with any signatures at all, and there's no way that I can assume a message is not genuine merely because it lacks a signature, even if it's from a user who frequently signs their mail.
even Windows has a fine-grained security policy these days. Except that there is absolutely no useability in it, none whatsoever. Even if you're an expert, it's hidden away deeply.
I do agree with this. I've actually noticed it for awhile -- I do it somewhat haphazardly myself, but there really does need to be a better way to instantly spawn new users (or at least contexts) for new applications.
To be fair, we do have a platform which does this automatically -- the Web. And many native applications would need to be changed to work with greatly reduced privileges, especially to be usable in that case -- many programs, I w
A light switch works so well precisely because it gives you two options: "Lights on" or "Lights off", instead of presenting you with a spectrum of things you can do with electron flow through a wire.
Mostly because, in that situation, it would be useless.
By contrast, despite being automatic, my car's transmission also has a first and second gear and an overdrive toggle, not to mention neutral and reverse. That's just the transmission -- my car also has four separate braking mechanisms, each with their own unique interface. It may be possible to simplify this, but people are willing to put up with this situation from a car.
Take a moment to look into a car sometime. Count how many separate controls there are, and remind yourself that this thing's purpose is ultimately to move you from point A to point B.
As Einstein said: Make things as simple as possible, but no simpler.
Sure, some Apps would not be accepted in the App Store, but I can still put them on my own devices, no problem at all.
Define "no problem at all" -- as I understand it, you're describing a scenario which either requires a jailbroken phone or a dev kit.
The difference really isn't that massive. For the user, light switch, coffee machine, car, computer - all just tools to enable him to do what he wants to do. Sure, some of those tools have multiple functions, and computers probably the most. But still a tool.
I'm sure even our hypothetical user can tell the difference between a coffee machine, which takes perhaps two minutes of instruction (if that) on how not to get burned, and a car, which in many places takes several months of training before you're legally allowed to drive on public roads.
A few years ago, a magazine did a test on phishing, giving well-made phishing mails to both novice users and security experts to let them say whether they think they're genuine or phishing. Turns out, the statistical difference between the two groups was not so high.
So, which magazine, what was the threshold of "security expert", and what was the proposed action? I might say that an email looks legitimate, and still not click anything inside it.
The main problem with phishing is that most of our e-mail programs seem to be designed to make phishing easy and noticing the details you need to notice to make the distinction as hard as possible. Almost all the information that is available that makes it possible to discern a phishing mail is hidden away somewhere. Meanwhile, all the information that triggers your mind that you need to react on this important mail - i.e. click on something - is large, in-your-face, middle-of-the-screen.
This is what a naively "simple" design would call for. I can certainly look at headers (or the raw message) when I suspect something, but when I leave it on, it's annoyingly difficult to get through normal email -- users wouldn't have a chance. If we make it harder to click on things, we penalize people sharing links instead of pasting the entire article into the body of an email, among other things like registration links and such.
So you simplify it -- make everything open when you click it, and hide away the scary headers so people don't have to learn about them. Until they do anyway, because they need to be able to check whether a message is forged.
More importantly, simply clicking a link from a phishing email isn't likely to cause harm unless you also fall for the site it's linked to. I haven't seen a proposal for any way to make this better which doesn't come with significant drawbacks -- and here, the information is "hidden away" in the URL bar.
That's nonsense. Where do you have any evidence for that claim?
Which one? That the only way around is a whitelist, or that Apple and China seem to want whitelists?
I don't have any evidence that China wants
I'm an iPhone developer. There is no "dumbing down" here at all.
For the user?
Anything I want it to do, I can make it do.
Jailbroken?
the user has most of the complicated stuff hidden away from him.
In the case of the iPhone, it's not that the complicated stuff is hidden. It's that it's actually forbidden -- see above. Can you make it do anything Apple doesn't explicitly allow?
That is not a conspiracy,
I never suggested it was.
Nor do I think Apple and China are in a conspiracy to censor technology -- they just seem to agree (quite publicly and openly) that computer users need to be protected from themselves, beyond the point of making it simpler and more usable, and to the point of removing choices.
Look at cars: Early on, you'd better know quite a bit about it, just to drive one. These days, you put your car into the ignition, and you care nothing about what goes on under the hood.
I do, however, care that the hood is not welded shut. I care that like most drivers, I also know how to change a tire and jump a car -- and jumping a car is something that it's useful to be able to do once in awhile.
Do you know how to make fire without matches?
No. However, I do know how to properly use matches. I know that even when a match is out, I shouldn't immediately put it on something flammable.
How to milk a cow?
No, but I know not to drink spoiled milk. Do you see where this is going?
I'm a technophile, I'm hardly a Luddite. I do appreciate things getting easier, and I said so. But there is a limit to how much I can avoid learning because of technology. Safety matches are better than normal matches, but you can still (easily!) burn yourself.
What you need to do is teach them which tasks require elevated priviledges and to become suspicious when something else, such as their mail program, suddenly has a red border.
Then they will come to me every time they see that, and when I get sick of it, maybe they'll believe the email that says "Don't be alarmed when Outlook's border turns red, this is part of a normal email virus scan."
In this case, the basic principle is applicable to more than just this one thing (window borders), and is also not terribly complex. In particular, understanding the concept of trust will also help them understand what those scary certificate warnings are actually asking, why they shouldn't download random crap, why they should lock their computer when they're away from their desk, and so on.
And it takes on the order of ten minutes to explain to an intelligent (but nontechnical) person. I speak from experience here.
the better support your tools give, the less education you need.
I'm not sure that's true. Hopefully less rote learning, sure -- I know dozens of commands by heart, and whenever I need to teach even one to a novice user, I consider that a failure.
But the fundamental concepts haven't changed much, and can't be made much simpler without removing a crucial bit of understanding. Teach the underlying principles, and all the specific rules ("Only these three programs should ever be red!") become intuitively obvious.
I also insist that there is far more idiot-proofing possible than we tend to think. If you study design for a bit (not the computer stuff, the real-world stuff about light switches, doors, coffee machines, etc.) you are quickly surprised at how much a good design can solve. Our computer interfaces are worlds away from that at this time.
A light switch controls one or more light sources. At the very best, it can control brightness on a scale (a dimmer) rather than a simple boolean on or off.
Doors are open, closed, or revolving. Some automatically open and
It's not about memorizing facts, or about recalling something, it's about knowing what you know and what you don't know. I don't know how to use a chainsaw properly, but I know enough to know that I don't know, and that I would need to learn how or I'm going to get hurt.
If it is easier to simply design in a safety than to educate everyone and keep them educated, then building in the safety is the proper thing to do.
That's true, if the safety has no downsides whatsoever. Otherwise, it bears more discussion.
For example, the iPhone and the Great Firewall of China, both of which claim to be making things more secure and stable for you by removing your choice. Even if the iPhone is more secure for the kind of user who would download BonziBuddy, I don't think it's worth it, and this is exactly what is meant by dumbing down. Compare that to your idea:
I still don't understand why current operating systems don't indicate the priviledge level an application is running at by, say, a coloured border. You'd still need to educate people on what it means, but a fairly simple safety gives them a lot more options than the stupid "well, you could open a console and run ps" geek solution.
But for this to work, you need to educate people on a hell of a lot more than "Here's a colored border." You need to educate them on what privilege separation means, why they might trust or not trust a given program, why they should trust things as little as possible, etc.
It requires fundamental education, much like you'd get from driver's education, to be truly useful. Yes, we should include antilock brakes, but those cannot be a substitute for knowing something about hydroplaning and ice.
You don't need to know how to change your oil -- you can pay someone else to do that. You don't even need to know how often to pay someone else to change your oil. You just need to know that cars occasionally need maintenance, and that before buying a car, you should learn what you need to know to maintain it.
To bring it back to the original "fire" example: If there are no disadvantages, we should make it so no one wants to look into their gas tank with a lighter. But there's a limit to how much idiot-proofing you can do. If you don't teach people that fire and gasoline don't mix, or about flammability in general, stupidity will find a way.
DVD has a capacity of 10 mbits. Blu-Ray has around 50 or 60.
And that's just a single video stream. Now imagine a household with more than one person wanting to use it...
Now, granted, everything probably will be compressed to hell, because at this point, it's no longer your ISP that's the bottleneck, it's theirs. There's also a lowest-common denominator factor -- content will be made to serve those at 1 mbit, not those at 100.
Still, asking why you need that is a bit like asking why you need any technological upgrade. You don't, yet, but if it's there, someone will find a use for it.
They are not, however, necessary in their current form. At a bare minimum, you no longer need a three to six lane highway to handle people, just one lane for freight and utility.
As long as we're going nuts, there are ideas for how to handle package delivery. I don't know how practical a pneumatic tube system would be, but it's an idea.
First, I think the idea was to replace that 3-lane highway.
But the "so what" is for this part:
One person trips, next thing you know you have a pile of bodies and all injured.
Same things happen in cars. Or are cars inherently easier to control than our own bodies?
I haven't bought a single Sony or Apple product lately. I still use the Apple keyboards I have, but when that wears out, I'll definitely be looking for something else to replace it with.
But you're right, it does seem people in general have done this.
On the other hand, Xbox 360 doesn't limit disc games to one user account nor require periodic Internet activation to play offline.
Fair enough -- but that's disc games.
I guess the lesson is that if I mostly bought physical games, or rented them, I'd use a console. For downloading games, I'll use Steam or find things DRM-free.
Ping times.
I honestly don't get it.
I've played Halo over the Internet. I've played Counter-Strike over the Internet. I've played Quake 3 over the Internet. All of these are fast-paced action games, and all of them are perfectly playable.
I've played it against people on all sorts of ISPs, and certainly, anyone close enough to be coming to my house to play is going to have a decent ping time. I've also played it against people in other cities -- bring up a server list, sorted by ping time by default, or let Xbox Live match me against someone decently close.
Is Smash Bros actually faster than these other games, somehow? Or did Nintendo manage to screw up multiplayer?
I'm glad not everyone on Slashdot buys into the common assumption that kids don't matter.
It's not kids necessarily here, it's that there are other priorities to spend money on than games.
You might be thinking of the "think of the children" meme, which is about something else entirely. It's not that children don't matter, it's that they're often brought up as a purely emotional argument, even a red herring -- for example, it's reasonable to think of the children and then restrict the sale of certain games to minors. It's not reasonable to think of the children and then try to ban certain games from distribution to anyone.
Not a Mac, but an iPhone/iPad.
Macs don't restrict what software you can install on them, other than by not being Windows. Anything you can port, you can run, unrestricted. This is not the case with consoles or iDevices.
The only thing locked to the original machine is offline mode.
That's pretty significant, and also a restriction Steam doesn't have.
there are genres where Internet play doesn't work so well either, such as fighting games.
How so? Why wouldn't that work over the Internet?
I guess that's a genre where there isn't a downside to local multiplayer, but I don't see the downside to multiple screens -- other than, again, cost.
For a lot of households with children, including my aunt's, money is a factor.
Agreed.
for real, you are asking me 'so what' and that's your argument?
I'm sorry, I could've been more specific:
- Why is it important not to call the server as often, especially when HTTP caches will do the work for you?
- Why are you comparing a complex Java app (or applet) with a "simple" HTML design?
- What does "large" amounts of data have to do with it?
Some of my users think that their 'computer is broken' when somebody re-sizes a window on their desktop,
If your argument is that Java is a better environment for dealing with this particular class of users, I guess you win. That sounds like the same class of users who got bent out of shape when I attempted to migrate them from Outlook to Thunderbird, and Thunderbird didn't have their emails colored the way Outlook did. Seriously, they categorized emails by color.
Those users are a lost cause for doing anything really interesting. There's a pervasive attitude in the non-IT world that even people who sit in front of a computer their entire day, whose entire job entails working with a computer, should somehow not have to be computer-literate, that it should be someone else's job to install antivirus, update their computer, keep it clean, and filter their Internet so they can't screw it up.
I think the Web can do this, if not now, then soon. But I also think that recreating an existing app for such users isn't really an example of "new development" that the AC was talking about.
Rendering done by the Java applet is completely different from what a browser does.
I'm sure it is.
Browser needs to parse HTML out, it needs to create some form of a document (DOM) it needs to prepare for quirks...
So if you've got a fully compliant page (thus, you don't trigger quirksmode), you don't use InnerHTML, and you do create and update the table with JavaScript, you're not always triggering every stage of that, or even most of those stages. You can even avoid reflows.
Java applet has none of those issues, it does not need to parse out any documents,
Other than the document containing the Java applet, and you'll need to parse something to get at the data.
as a result it responds immediately. 1 second after I load the 20,000 rows into it I can scroll ALL THE WAY TO THE BOTTOM. At this point a browser rendered maybe 300-400 rows only...
...if you rendered it as a simple HTML table. I'm fairly confident I can match what you've just described.
Now, you're claiming that you can just render a 20k row table in Java, but what is that "rendering" actually doing? Do you have a pixmap of the entire table in memory? Or are you loading it into some Java library's concept of a "table", which draws only the relevant bits on the screen?
But that's exactly the point -- I can draw only the relevant bits on the screen with a Javascript app. It may take a library to do it, but it takes a library for you to do the same thing.
- for a compiled language it is not that much more verbose than C or C++, in fact less so depending on what you are doing.
Define "compiled language" -- that's an implementation detail. Lisp is a compiled language.
you have no idea what you are talking about. GWT is not a library.
Why is this important?
if GWT was written in C or C++ or PHP or whatever it still would have been as bad in terms of amount of code as GWT is with Java right now, not because of Java but because of what GWT is doing. GWT architecture requires much more code to be written that will have to be translated into Javascript/HTML
It may be an issue with the architecture of GWT, but I don't see how it's at all related to any particular badness in HTML.
You were the one who brought up GWT, to say that
Not any more than the original Xbox was a PC.
Having the same hardware doesn't make it a PC. Being able to mod it and run it on a general-purpose computer, with a general-purpose OS, is what makes it a PC.
At least console DRM allows lending game discs to friends and resale to GameStop or to eBay buyers,
That's the single killer feature of console games, and something I wish Steam would implement. The closest it has is, if you somehow end up with an extra license (due to, say, buying two bundles with overlap) you can give a copy away.
As with WiiWare and Xbox Live Arcade.
Do either of those allow re-downloading those games (for free) on a new console? With Steam, all I need is a username and password.
most Steam games need four PCs and four copies of the game for four players.
True, but deals can be had to make that less painful, and there are genres for which single screen really doesn't work well. Halo comes to mind -- as much fun as it might be to have the option, if I have four friends (and if money wasn't a factor), I'd rather have four networked Xboxes than one.
Look at Stardock's Impulse, or Penny Arcade's Greenhouse.
Now, it may be the case that such a system can't be successful, but there's nothing stopping anyone from doing digital distribution without DRM -- in fact, it's much easier to do so. It's just that Steam's DRM is what many people (myself included) consider to be a fair trade.
There is a version of the GPL which specifically addresses this. It's a loophole in the spirit of the GPL, though not the letter, just like Tivoization.
Yeah, I know, we've seen Scala and Clojure, but they're rather shitty and impractical for large-scale real-world software development.
Be specific. How are they impractical? In particular:
Clojure is just a reimplementation of one of the oldest programming languages around, Lisp.
And what's impractical about Lisp, particularly a Lisp with STM?
It's also funny that you mention this:
Sun's lack of vision over the past decade has rendered Java far behind languages like C#, Python, Ruby, and even Perl.
Here's the thing: For awhile, JRuby was faster than MRI, the main interpreter. YARV, the new MRI, is faster still, but JRuby seems to be catching up. And JRuby can do real threads, without a GIL, something MRI can't or won't. It runs all sorts of stuff Ruby people expect, including Rails. There are even a few examples of Java libraries which had Ruby equivalents, but the Java versions are the only ones still maintained -- for example, DataMapper supports Oracle just fine, but the only current low-level Oracle adapter that's supported is the JDBC one.
Then there are the crazier things, like running Rails on Google App Engine. I don't necessarily like the JVM, but it does mean I can run any language I like so long as it fits into that Java container.
I'm not sure how close Jython is to that kind of status, but I've been forced to develop stuff which runs on Oracle's WebLogic, and, surprisingly, the WebLogic Scripting Tool is written in Python, and runs on Jython.
It's also funny you mention Perl. What's the #1 reason for using Perl? CPAN. There's tons of Java libraries out there, though not as nicely organized as CPAN last I checked. If I were to take one such library -- say, a nice, well-behaved, self-contained jar -- I could use it trivially from my Ruby app. The Perl concept of grabbing existing CPAN libraries, maybe some only thin wrappers around C libraries, and binding them together with a thin bit of scripting glue to make something cool, is definitely alive and well here -- except you don't have to write any glue, it's trivial to just use the Java APIs.
So, I hate Java as a language. There are languages I merely dislike, or prefer not to use, like Python or Erlang, but I actually hate Java. But the JVM looks like it's turning into something cool.
The JVM is an absolute mess compared to .NET, of all things.
Except that .NET really isn't even to the point the JVM is for "write once, run anywhere." The main implementation is Microsoft's, and Mono is always two or three steps behind. You can either write stuff using Microsoft's APIs and hope Mono keeps up -- which would be like declaring your Windows app is "cross-platform" because it runs under Wine -- or you can stick to purely Mono stuff, which means you'll have to distribute native libraries (like GTK) with your app.
I think I've given up looking for the perfect VM. I'm sure the JVM isn't it yet, and I would guess that some other VM will take over. After all, the JVM physically can't (and may never be able to, may never want to) do some of the tricks the Erlang VM does.
But you're writing Scala and Clojure off as "shitty" without giving a real reason why, and you're either claiming people aren't using Java (or the JVM) for new development, or saying they're stupid for doing so. Where you're not factually wrong, you're just spouting opinions without backing them up.
If you're the same AC, that's a remarkable change of position -- you seemed to be claiming that Java wasn't seeing new development, and now you're claiming that it is, and it's just stupid.
Java in a browser is a much better environment for desktop like applications that need to handle large amounts of data without constantly calling the server than a simple HTML design that requires the browser to render all of that data.
So what?
An HTML page with a table that has 20,000 lines with 8 columns takes just under a minute to render (depends on a machine, but it's a good estimate) and it only takes a second (or less) to render in a Java applet with the same table.
And I bet a Java applet which attempted to render 20,000 lines all at once would perform just as poorly. It really wouldn't take much JavaScript to replicate what Java is probably doing here -- render only the rows which are actually visible, and cache the rest in RAM.
Your mention of "constantly calling the server" suggests that would be a bad thing, too. The browser's HTTP cache works with XHR, so I really don't get where that's an issue unless you need the data to be downloaded all at once.
hundreds of times easier to do in a Java applet than in HTML, never-mind gwt or any other help you can get from any libraries, Java+Swing is still easier to write than anything in GWT
And did you try anything other than GWT? Certainly, if you're going to claim this:
it takes much less code to get the same functionality as well.
Java, as a language, is verbose as hell, so I would guess that a Java library that outputs HTML is worse than a Java library that talks directly to a graphics system. But those aren't your only choices -- JavaScript is decent, and has its own libraries.
You're also assuming that the functionality you get from Java is worth the functionality you lose. You're now requiring people to download a plugin -- no, not everyone has Java already, certainly not a recent version -- and your app is now rendered as an opaque blob, which means users can't script it with greasemonkey, it doesn't work with back/forward or bookmarking, it can't easily interact with other things on the page that want to behave like a webpage... Believe it or not, there are places where the Web beats a desktop app.
You may be able to replicate that native web feel, but that's going to take a hell of a lot more code than it'll take me to develop a decent native web-based app.
I'm not saying I agree with AC, but I really don't see much of a reason for doing browser-based Java -- though I do use it on the server side for other things.
But he's also still trying to get the last word in, claiming 'I still don't think they're art, I just don't want to discuss it'
I don't know that he's even doing that. I suppose this part you mentioned...
I had to be prepared to agree that gamers can have an experience that, for them, is Art
But see, art is subjective. Many of us tried to make that point. I don't have a problem with this statement unless he's outright saying they're wrong.
He never said once, in this entire article, that he was right and that videogames are not art. In fact, the tone of the entire article is, "I may well be wrong about this, and I was certainly wrong to pretend to have a valid opinion in the first place."
He's being skeptical, which is fair. But he's also being honest. Read the next few sentences:
I don't know what they can learn about another human being that way, no matter how much they learn about Human Nature. I don't know if they can be inspired to transcend themselves.
Note: "I don't know." And then he continues:
Perhaps they can. How can I say?
There it is. That's exactly what I wanted to hear out of him. I can't ask for more, so long as this is the case:
I may be wrong. but if I'm not willing to play a video game to find that out, I should say so.
I know it's cliche, but I have actually had a situation where I needed a Linux ISO ASAP on a college campus. BitTorrent was the fastest way to get it.
Fortunately, Iowa State University's current policy is somewhat sane -- they sent me an email that I should be aware I'm uploading, and did absolutely nothing else.
My guess is that this actually does curb piracy, but it does so without violating net neutrality or hampering legitimate, educational uses. More importantly, that system probably costs them way less to set up and maintain than anything pro-active, as it still lets the MPAA do the heavy-lifting. I assume they'd just pass any letters from the MPAA (including legal action) straight on to me, thus meaning they have no legal liability one way or the other.
This would reverse all of that. It'd make the school responsible for policing what students are doing on the school network, and thus, the school would be responsible if they aren't effective. In fact, it seems to be operating under the assumption that this is already happening. The University of Iowa, I'm told, functions this way, but any university which does anything to hinder piracy is not doing themselves any favors.
On a console, I prefer a physical disc, because at least that way, if I lose/break the console, I don't lose ALL my games.
With Steam, or anything similar, or anything actually DRM-free, I would much rather have a digital download. It's far more convenient, so long as I can actually, legitimately, easily make backups -- or, in the case of Steam, Valve has it backed up for me.
He's saying something much more honest, insightful, and true than he's getting credit for.
He seems to be saying that he not only could be wrong, but that he really isn't qualified to comment. He's admitting that he's not willing to get the required experience (play enough games) to be able to comment and be taken seriously. Given these two things, he's bowing out.
Now, it does seem like it took a lot to get it here. It seems he's acknowledging that he was "bull-headed" and that he's mostly writing this because of the barrage of criticism he's received. But what he's actually said is right on -- he isn't qualified to comment, and if he really wants to, he'd have to both solidly define art and play some games, which he's not prepared to do.
I don't have a problem with "backpedaling". I don't like that it took him this long, and I do wish he was a bit more explicit and humble in his wording. But he's realized exactly what he should have, given his experience, and he's said so. I wouldn't expect more.
I only saw a proof-of-concept. Have people actually been exploiting this?
comes with a decent framework to start with.
What does it come with?
It's not a good comparison to compare a language to a framework, and attacking the language for the lack of a framework,
The problem is, once you add a framework, PHP loses every last advantage it had over a real language. It becomes bigger and slower (so, may as well use Rails), and it's no longer something that everyone just knows with no training (so, may as well use Rails).
PHP is not inherently unmaintainable,
To the extent that a language can be unmaintainable without trying, I think PHP is about the worst out there. I'd again draw an analogy to C -- you can make a good Web framework in C, and you can write good, maintainable web apps in C. But why would you ever want to, when you have better options?
security issues with PHP apps has nothing to do with the language, but lack of programmer skill.
mysql_real_escape_string() wants a word with you. Yes, you can abstract away the shit that is the basic language, but you can do that in any language.
no framework spaghetti relying on globals
Do you know why the legacy code is written that way? Last I checked, PHP still didn't have properly scoped variables. Your choices were global, function, and, more recently, instance. Contrast to a decent language, like, say, JavaScript, which supports proper local variables.
I mean, objects were tacked on in what, version 5? So it's hardly a surprise that you've got piles of non-OO code -- but PHP doesn't have any of the tools you could use to build proper OO, like real first-class function pointers (or references, or closures, or anything like that), so basically, if you wanted any concept of state that you didn't pass around from method to method, you needed globals or the database.
And the database was a mess. How recently were actual parameterized queries added, so we can stop doing mysql_really_escape_everything_magically_i_mean_it_this_time_plz()?
Why a lot of PHP is such a garbled mess then? Low barrier of entry, a lot of complete newbs has been using PHP as their first touch to anything programming.
Same with Rails, but it's not nearly as much of a mess.
Just count how many language side security flaws PHP has nowadays... Right at about 0.
Is that uncommon? I bet gcc doesn't have many segfaults, either, but that doesn't mean C is a good language to use if you don't like segfaults.
Go with experienced developers, who actually think and know what they are doing, and not the novices who don't know what they are doing.
That's true regardless of the language. But while you're at it, why not give those experienced developers a tool that actually helps them, rather than getting in their way?