And on a side note: As a NoScript user, I'm surprised that I've had to give Javascript permissions to Twitter just so I can visit that idsoftware.com link inside of the tweet. Obviously I don't visit Twitter often, but that should never be the case for it or any site.
And I'm sorry, but if you turn off javascript this day and age you should expect more sites to not work then to work. You're turning off part of the browser, and you do not like having to turn it on to use the browser? Seems a little backwards to me... considering the extremely small population of noscript users.
I also understand that I'll probably get down voted into oblivion as every single noscript users is probably on this site. But it's true...
But Twitter's main purpose in life, for end users, is to display text and links. There's absolutely no reason why disabling javascript should cause a link to be inaccessible. This is a legitimate complaint.
Anyways I agree that he should still be able to see text/link. But I turned on the site in Google Chrome, with javascript turned off... And it worked perfectly fine. He however has "noscript" which does not work that way, and does stuff preventing the site from doing normal functionality... Completely his fault.
Twitter is. Twitter is an absolute clusterfuck technology wise, they are the prime example of doing everything wrong. Defending their idiocy does not reflect highly on you.
I personally block Flash by default (mostly to stop audio ads), and I have no problem turning it back on when a site requires it.
I don't know what's happening to web development, but since this app fever developers are fighting for eye candy and LESS accessibility. Sometimes I see a page that fails to work without JS, open the source and see just JS code. Where is the content? Web apps are often times also walled gardens, and completely break the functionality of the browser (based on linking, rendering text & images and using the back button).
Now even simple websites completely disable access to content just to show some silly animation.
The move to "web-page-apps" is not about eye candy, it's about speed, responsiveness and yes, usability. About not trying to awkwardly force an app down the http/html way.
A broken website/app is simply broken: if things do not work as expected, that's not the fault of webapps per se or JavaScript - it's all doable and not a big deal anymore (the back button thing).
No, it is about following fads, just as web development has always done. Creating sites that are slower, less responsive, and offer terrible usability is clearly not done for reasons of speed, responsiveness and usability. Enhancing a page with javascript can increase responsiveness and usability. Replacing the page with javascript is moronic.
Sorry for the PowerPoint presentation: http://www.cs.princeton.edu/~dpw/popl/06/Tim-POPL.ppt
The crux is that there are a lot of tools available when working with functional programming languages that allow programmers to avoid pitfalls common when working with mutable structures. The fact is, game programming is very different in some ways from, say, web programming. In web programming, you modify small parts of the system at a time and you probably have a nice database with ACID guarantees, you can wrap changes in a transaction and get on with your life, or just make small changes without transactions. Games just use big collections of in-memory objects to represent a complex state that changes significantly every frame, and if that was how your web application worked you'd probably call it fragile.
I can give a more concrete example. Suppose you write a quick game where you shoot missiles at invading aliens. You register a collision between the missile and the alien, so you send a "collide" event to both. Except the missile responds to the collision by exploding, which deletes the alien object, and in C++ you might send a "collide" event to a dangling pointer instead of the alien space ship.
Yes, there are lots of tools you can use to fix this. "Use immutable data structures" is one of the more fool-proof ways to do it. So right there, by using immutable data structures everywhere, you've eliminated certain classes of bugs.
This becomes more important when you have multithreaded applications: immutable data is just inherently nice when you're using several cores: you can get rid of a bunch of locks and other synchronization techniques, many of which are a constant source of difficult-to-debug bugs for even experienced developers.
Was a rational thing to do? Maybe not, but it was fun to do.
It's not about the result, but the process of building it. Lessons learned can be applied to situations where the result does matter (and, hopefully, blogged about).
Really? Because it works just fine for me. Maybe they're doing some sort of A/B testing or partial roll-out around links?
I think its still too early to say that Haskell gives immediate, quantifiable, benefits for multithreading but it sure gives more avenues to tame your code and lots of freedom for people to code different concurrency solutions on top of it.
It's probably along those lines, though I doubt his wife and kid(s) would allow him to do that these days ;)