The top comment states that any other options are impossible: "At this point we must concentrate on improving the language."
I can't stand this willfully defeatist attitude. It's also not restricted to stack-overflow participants -- this position is pervasive at Mozilla.
Why can't we have a standardized generic bytecode and VMs to run it? Why should the web be locked to a single language forever? Can you imagine if we had locked desktops and mobile only a single implementation language?
Mozilla is not against a bytecode VM. Mozilla (and the WebKit team minus Google) is against arbitrarily adding new language VMs because they create a major compatibility burden. Remember this:
2) That means that adding additional languages creates a burden. You're now supporting, at minimum 2 VMs. If you're going to support a second VM you better get it positively right. That doesn't proclude doing it, it just means it's not coming tomorrow.
> That means that adding additional languages creates a burden. You're now supporting, at minimum 2 VMs. If you're going to support a second VM you better get it positively right. That doesn't proclude doing it, it just means it's not coming tomorrow.
The position more seems to be "we might chip in if someone else comes up with the perfect answer" rather than "yes, this is a problem that needs to be solved to improve developer productivity, application quality, and help the web compete with other platforms".
True, but the JS VMs we have today have been refined over 15+ years and switching to another risks breaking the web in profound ways. Even Google would be against dropping V8 for JS use.
>The position more seems to be "we might chip in if someone else comes up with the perfect answer" rather than "yes, this is a problem that needs to be solved to improve developer productivity, application quality, and help the web compete with other platforms".
I read the mailing list and that's not the impression I get at all. The impression I get is:
3) For those who have a general syntax/style problem, there are numerous alternatives that compile to JS to choose from, and more are likely to become popular in future as programmers from different backgrounds are compelled to write for the browser.
> True, but the JS VMs we have today have been refined over 15+ years and switching to another risks breaking the web in profound ways. Even Google would be against dropping V8 for JS use.
And yet, Google, Apple, AND Mozilla have all successfully introduced entirely new or significantly refactored VMs in the past few years.
This is solvable; it HAS been solved.
In that regard, failing to allow others to implement custom/experimental languages seems counterproductive to the ultimate goals you seem to be stating here.
> For those who have a general syntax/style problem, there are numerous alternatives that compile to JS
In terms of performance, debugging, profiling, and simple functionality, compiling to JS is simply a work-around, not a solution.
> Why? What critical problem requires a bytecode VM? Developers refusing to write in anything but their favorite language?
Your argument was that it wasn't technically achievable because it would break the web, yet it's clear that it can be done and HAS been done.
I'll try to address this new argument.
JS isn't perfect, it will never be perfect, and the lack of a bytecode VM is a hindrance to experiments and production language implementations that can lead to better solutions for developers.
Look at the language design that has occurred elsewhere. I may not use Erlang, but I learned a lot from it. Clojure introduced a ton of interesting concurrency constructs (among other advances). C# demonstrated LINQ, and F# is OCaml revisited.
> This is solvable without alternative VMs. WebKit is working on CoffeeScript/other language debugging:
Excuse my ignorance, but what browser-based non-JS VM was introduced successfully? You mentioned this was done before, and I assume you mean it was done successfully, so just curious to know which one it is?
We were actually discussing JS VM replacement in the browser, related to:
> True, but the JS VMs we have today have been refined over 15+ years and switching to another risks breaking the web in profound ways.
The counter-point being that all the major browser vendors have swapped out their VM or performed significant rewrites in the past few years; it's clear that it's possible to implement a new VM and not "break the web in profound ways".
I think you are misreading that quote. It's not replacing a JS VM with another JS VM that's a problem, it's replacing a JS VM with a non-JS specific VM would cause problems and break the web (something that has been proven to happen).
Arguing that you can replace a JS VM with a JS VM doesn't help the case of replacing a JS VM with a non-JS VM.
At the surface level, I could see how your position would appear logical.
However, the nature of the replacement VM doesn't really matter in the context of what we're describing here.
The problems of compatibility remain the same regardless of whether the target VM is a JS-specific VM, or a general purpose VM; reliance on undefined behavior, accidental changes in semantics, optimization bugs, and so on.
If browser makers were able to swap-out the VM, they've already demonstrated the ability to solve the exact same kind of compatibility problems they'd face here.
A VM that provides a standardized bytecode and execution model capable of executing most modern dynamic and static turing complete languages with sufficient performance. This requires more general facilities for common functionality required; refer to tail call support, JVM's invokedynamic, etc.
Or, shorthand, a general purpose browser VM.
Unless, of course, you're arguing that the above is not truly possible, in which case I'd argue that's exactly what Google is exploring via PNaCL, and has (if not completely efficiently) been implemented across existing VMs. The PNaCL choice of LLVM bitcode was likely in error, but regardless, "no such thing" is a stretch.
>> JS running on a general VM would be slower. That's against the interests of the user.
> What do you base this on? It's sounds like an unsupported assumption
No, he is entirely correct.
The fact is, despite all those efforts, even Microsoft did not implement JS on .NET in IE. This despite Microsoft more than anyone having the capability and moreso the motivation ("everything on .NET"). Microsoft gave up and implemented a new JS engine in native code, and it made that new native JS VM a peer of .NET in Windows 8.
The reasons for this are technical: We do not know how to make a single VM that runs all languages quickly. It's very difficult to do! Dynamic languages need hand-crafted PICs for example, which are extremely difficult to make portable and safe, which is necessary for a VM on the web. Also, low-level details like even how to implement numbers are significant: NaNboxing for example is used in most JS engines, but it probably doesn't make sense in a static language VM. Having both NaNboxed numbers and 'normal' ones in one VM is cumbersome and complex.
I'd argue the opposite regarding tremendous efforts and motivation; dynamic languages were an after-thought for both the JVM and .NET, and on the JVM side you've only seen any attempts to improve performance recently, with invokedynamic for Java 7.
The investments here occurred long after the VMs were developed.
> The reasons for this are technical: We do not know how to make a single VM that runs all languages quickly.
The same applies to compilers across the board; we do not know how to make a compiler that applies all possible optimization available to code always, either. I still have to manually vectorize critical paths, re-order code (sometimes in C!) to help the compiler avoid pipeline stalls, etc.
Instead, we do the best general purpose job we can, and it's usually more than fast enough.
What we're talking about here is a VM that has JS support as its first-order target. Using the JVM and CLR as performance examples here -- given what they were built for, and when -- is not particularly valid.
Speaking to NaN-boxing in particular; it's one solution to the problem, but not the only one. I'm going to remain unconvinced here, given that dynamic languages have almost always been a late, second-tier concern for anyone investing serious R&D in the development of a VM/JIT/compiler.
All that said ...
> The fact is, despite all those efforts, even Microsoft did not implement JS on .NET in IE. This despite Microsoft more than anyone having the capability and moreso the motivation ("everything on .NET"). Microsoft gave up and implemented a new JS engine in native code, and it made that new native JS VM a peer of .NET in Windows 8.
> I'd argue the opposite regarding tremendous efforts and motivation; dynamic languages were an after-thought for both the JVM and .NET, and on the JVM side you've only seen any attempts to improve performance recently, with invokedynamic for Java 7.
> The investments here occurred long after the VMs were developed.
That's a valid point. It is possible that some entirely new kind of VM could work, that was designed from the ground up for both static and dynamic languages. But I don't think we have any good idea of such a thing!
Until we do know how to do this, replacing the JS VMs in browsers would slow everything currently running. And adding another VM alongside it would decrease speed in other ways (see for example the papers that the Apple dev mentions in the WebKit discussion for why Apple opposes adding the Dart VM into WebKit).
It's not the lisp extremists that want this, it's the Python and Ruby ones. Lisp people already have plenty of options: I can think of ParenScript and ClojureScript off the top of my head. (And I'm not even (much of) a Lisp weenie. :)
The same thing could have reasonably been said of Flash just a couple of years or so ago. It was on something like 99% of browsers.
> That means that adding additional languages creates a burden. You're now supporting, at minimum 2 VMs.
1. That single VM.
Then, if someone prefers to work in Python or Ruby (or Lua, or whatever), they can compile to the byte code on the server, and send the byte code to the browser.
1) It will undoubtedly be slower than the current JS-quirks optimized VMs.
2) There is a shit-ton of JS on the web that has been tested to work with the current crop of VMs, moving to a new VM almost guarantees breakage. It's the same reason why GNU Screen isn't rewritten despite (supposedly) being a mess.
You're not the first person to posit that adding a new VM "almost guarantees breakage". So what? Keep the old VM, transition to the new one by specifying that's what you're targeting, then deprecate the old VM and eventually lose it altogether.
You make it sound like the computing world has never introduced a new version of a language that has implications for the older ones and managed to overcome it. Even the web did this (remember putting your scripts in comment tags?).
> You're not the first person to posit that adding a new VM "almost guarantees breakage". So what? Keep the old VM, transition to the new one by specifying that's what you're targeting, then deprecate the old VM and eventually lose it altogether.
That means both VMs will be in the browser together at some point. That is a hard problem, for example because of cross-VM garbage collection (the WebKit thread where Apple refuses to accept Dart into WebKit references some papers on that).
This will cause an immediate slowdown on existing code, and a very large maintenance burden, for example you typically need to optimize fast paths in the DOM for your VM, with two VMs that is double the work, and if the VMs are allowed to communicate - and they can, if they can both access the DOM - then you have three paths to optimize now.
It's possible to migrate from one version of a language to another - say Python 2.x to 3.x. But they are not both running in the same process and communicating directly with a third shared environment like we would have on the web.
I'm not aware of anyone disrupting critical code the way you're suggesting. It would be akin to rewriting malloc. I'm not discounting a slow transition akin to what you suggest, but you're talking about a long time frame of supporting 2 VMs side by side. Probably 10+ years.
I do not necessarily think the web needs generic VMs to move forward, or that JS needs replacing (I happen to enjoy JS with all its quirks quite a lot).
I do, however, think that such a transition is possible if the powers that be (Google, Mozilla et. al) could agree on a fairly consistent strategy.
Yes, 2 VMs side by side would probably be needed for some time, but 10+ years? Surely pure JS VMs could be moved to plugin status and be phased out faster than that, especially since someone would just write a compiler that compiled JS to this byte code format. No, it wouldn't be as fast as a VM highly optimized for specific JS quirks, but it could probably suffice.
> It would be akin to rewriting malloc.
Custom mallocs has been written for many different purposes like for example demanding game engines. While certainly a complicated task, it has been done numerous times.
Why would <script> tags HAVE to contain JS? I see no reason why if we're changing to a generic byte code web, JS in <script> tags could be phased out as well.
A version of jemalloc specifically written for mozilla's codebase.
If it were a 100% compatible drop in replacement for malloc, why hasn't every other project switched to jemalloc yet?
(Searching for switching to jemalloc, seems like every group that tried it out found that their code base or use case exposed new problems in jemalloc. That these could be fixed doesn't negate the main point -- you couldn't just switch malloc out in existing codebases and expect everything to work right.)
I don't think I've ever seen a more dramatic real-world example of unwittingly strengthening the point you're arguing against. jemalloc didn't work quite as they wanted, so they customized it, and you really think that's a counterpoint to an argument for trying new and different things?
That nobody other than Google is making long-view plans for the future in this regard is somewhat insane.
If this is a complete puzzle to you, you might spend some time meditating on a parallel issue: why have we spent 20 years iterating HTML rather than proliferating various hypermedia schemes? Or "better" yet, some real universal client that works like Display Postscript or X-Windows?
Also consider that there have already been two freely targetable VM plugins which have had near total market penetration at various points in the web's history. Both of them were capable if flawed. One of them was even arguably massively successful. Why is the world moving on from them?
> why have we spent 20 years iterating HTML rather than proliferating various hypermedia schemes?
You have to remember that HTML is predated by SGML, and that HTML and its precursors were designed for the purpose of providing document markup. We've continued to evolve these solutions for document markup, and in this regard, they do an adequate job.
However, what we've seen in recent years is a rapid emergence of the use of HTML and JS for producing fully interactive, stateful, and performance-demanding applications. This wasn't due to the suitability of HTML for the task, but rather, due to the lack of any other reasonable standardized competing platform.
HTML has fallen over in this context; the DOM is ill-suited towards standard re-usable UI widget programming, JS is frustrating for building large applications, the performance profile is tremendously bad on mobile devices. This has led companies like Google to task teams with exploring how to fix HTML to be more amenable to application development -- whether it be dart, replacing the DOM, NaCL, or otherwise.*
> Also consider that there have already been two freely targetable VM plugins which have had near total market penetration at various points in the web's history. Both of them were capable if flawed.
Highly flawed. Java's plugin implementation was incredibly technically flawed (just look at the startup times), as was Adobe's (for different reasons). Moreover, Adobe Flash was not standardized, the documentation was sprawling and complex, and the bytecode format and libraries available changed significantly through the lifetime of the product.
However, this does not mean a VM isn't possible; that's what we already have today, with V8 et al.
> Or "better" yet, some real universal client that works like Display Postscript or X-Windows?
Would that be better? There are plenty of fundamental technical reasons those approaches for networked applications did not take off.
Of course, one could argue that <canvas>+webgl provide a modern successor. A generic rendering environment with client-side code execution.
> You have to remember that HTML is predated by
> SGML, and that HTML and its precursors were
> designed for the purpose of providing document markup.
I remember. I also remember there have been people arguing all along (back into the mid-90s, at least) that this document-centric approach has been totally unsuitable for a broader platform.
And yet, it's been more successful at delivering applications to the widest possible audience than any other platform. Why is that?
Enumerate all the features of the web you can think of that have enabled it to explode and thrive compared to networked applications and the popular VMs of the last 20 years. Then explain why you're certain that having a VM instead of a browser act wouldn't erode those advantages.
(This is the most important part of my comment. Feel free to ignore the rest.)
> HTML has fallen over in this context;
> the DOM is ill-suited towards standard
> re-usable UI widget programming,
I don't think the evidence is on the side of your claims. Given the sheer number of web pages and apps out there vs the number of desktop apps, the widgets built in to HTML are more widely used and re-used than most desktop API widgets, and the sheer proliferation of derived DOM-composite UI elements out there (particularly contrasted to the desktop) belies any claim of unsuitability for use: DOM elements are creatively styled and glommed together with a regularity that dwarfs anything from the desktop world.
> JS is frustrating for building large applications
How so? There are plenty of developers out there who've found that if you embrace the features the language and most runtimes offer, it isn't any more difficult to build large systems with it than any other language. Though despite that, the language seems poised to embrace some of the features from others if for no other reason than to make developers who already know another language more comfortable.
> Moreover, Adobe Flash was not standardized
Standardized enough that the runtime was successfully targeted by a number of non-Adobe products.
> the documentation was sprawling and complex, and the bytecode format and libraries available changed significantly through the lifetime of the product.
And of course, our shiny new standard VM will avoid all these problems over its lifetime. ;)
> the performance profile is tremendously bad on mobile devices
It's actually better than I'd expect in a lot of cases, but it's true that it's not good enough for a lot of kinds of apps. But the language is not what's causing the problem, so adding other languages won't fix it, and might introduce other problems.
Well, that's at least part of the reason why we disagree. The list is longer, and includes (but may not be limited to):
* view source - up until minifiers, there wasn't anything happening on the client side that you couldn't see how it was done yourself.
* gentle learning curve - the entry level to simple web publishing was achievable for anybody who could transfer "view codes" style word-processing concepts to markup and manage file transfer client. A little learning or some copy and paste could take you up the next gentle step to limited scripting.
* Hypermedia nature of the platform - instead of applications being little silos that only interoperate with a relatively small number of apps from the same organization (or other organizations where they've made deals), hypermedia docs were a sprawling web of connections constantly pointing to other document-applications. If you'd dropped a perfect universal VM on every desktop in 1995, it's extremely unlikely things would have fallen out like this. It certainly didn't for the imperfect one.
A 1995 release means that the first statement is only defensible given the flexible nature of popular. The second statement is truer in decreasing terms through 2004 or so, when it bottoms out.
That's tangential, though. The real question is more along the lines of whether the web would be everything it is now if instead of passing around a single strain of fairly standardized (though expanding over time) markup, we instead were sending drawing instructions and collecting events. Or maybe even a single binary-encoded standard for abstracted document trees designed for optimal machine consumption, generated from various different applications or compiled from other document schemes.
Their answers to that question are why a lot of people think it might be a better idea to have single scripting language, and the one we've got has turned out to be pretty capable so far.
I don't understand this fixation on js either. Even more, i don't understand the fixation on html, css and all so called web technologies. Common, web was never designed for the sort of applications we are trying to make it run. We need a totally new approach.
A totally new approach just means you have to support two incompatible standards, most likely with more bugs and inconsistencies than you have now. I'd much rather see all the browser momentum we've gained lately going towards more comprehensive support of the existing standards, as flawed as they may be.
On the other hand I don't like NaCL at all. Even with all the security measures, there is just too much risk in executing native code directly from the web. Also it splits up platforms, splitting the client world into x86 and ARM, instead of allowing for innovation in CPU-land by exposing are more abstract interface. It is a repeat of the "browser plugin" paradigm, which luckily failed.
To a large extent, I think apps are the answer here. (And just to be clear: I'm not conflating apps with app stores).
Consider the early days of the web: remember when Java applets seemed like the way of the future? (Okay, that's perhaps a bit of a stretch).
But I'm serious! What is the net other than a delivery mechanism for things?
How things are implemented is not the issue, the thing people really care about is easily getting software into the hands of end users. How that software happens to work internally is immaterial for most folks.
What if we do have a general purpose vm. Doesn't each browser still need to implement language compilers for all languages to that vm?
ie what if Microsoft supports langauge foo but not language baz. Chrome supports language baz but not foo and Mozilla only supports their own proprietary language. All of which compile to the common vm.
How do websites written for IE work on Chrome, and visa versa? Do all sites have to have their code byte compiled before shipping?
Then your stuck with performance differences and byte code incompatibilities at best, which is about where we are now.
I think this ignores the reality of the situation we've been in for a long time: different browsers do different things. We've all been quagmired in CSS because one browser renders one way, and one renders another. And we can't seem to get out of this, and it's always going to be this way for as long as there isn't one single browser, so let's just accept it and learn to deal.
Client-side languages have always been a choice that a developer has to make. Should I write my Windows program in .NET, or should I make my users install Python and write in that? Should it be compatible with Python 2.4, or is Python 3 good? Maybe I should just write it for Mac OS X, and that'll have Python 2.6 for sure...
It's for the developer to decide which audience he/she wants to accept/alienate. We've never thrown up our hands and gone "Oh gosh! All this platform stuff such a pain! Let's go back to C and UNIX and forget all this nonsense."
Yet this is the exact same argument being made for not moving towards a VM solution on browsers, and I truly don't understand it.
> Why can't we have a standardized generic bytecode and VMs to run it? Why should the web be locked to a single language forever?
In the beginning, this was the intended design. Which is why you still specify the language when injecting code into the page.
That original design is flawed and does not work well on the web. Adding other languages is a horrible idea.
> Can you imagine if we had locked desktops and mobile only a single implementation language?
Apples and oranges. On both platforms, programs rarely interact with each other and when they do, it's through the OS using a standardized API.
The web is different. One piece of code is always interacting with another piece of code, that is interacting with a third and so on. There is no standardized API. You just call the appropriate function, if available.
To implement other languages, not only would you need to compile to bytecode, add VMs, etc. you would also need to add APIs that would allow communication between different pieces of code, written by different people, in different languages. Even if implemented, which would be a nightmare, it would still stifle the very nature of the web, the very dynamism that makes web apps different.
I don't want the web to become like the desktop or mobile space. I want to pull in code from twitter, facebook, my code, etc. and have it all work together, communicate with each other, and create a dynamic environment, all on one page, client-side. This is only coming into reality now.
> The JVM and the CLR have already adequately demonstrated that multiple languages can easily (and with adequate performance) share common libraries and APIs.
When you try to make that work, you'll start placing restrictions on what can and what can't be passed. Global scope will be a nightmare. You'll try to hack together a scheme that casts responses into primitives. In the end, you'll end up with a stifling environment where interoperabilty is a theory that is never used in production because it was crippled to make it functional to the point of being useless.
This generally isn't the case with disparate languages on the JVM. Unless you have a concrete objection with a scientific basis, you're just spreading FUD, and I don't think that contributes to the conversation.
You then ask, "What if the response is a Date object?" You would call it the same way, and get back a Date object.
The rest of your question adds a bunch of other suppositions, all of them fairly vague and none of which seem particularly more salient than the first two. If you have a particular reason to think this would be intractable, maybe you could explain in more detail the problem you see, and perhaps an example of where it shows up in popular multi-language runtimes and interfaces.
> Your concerns seem ill-founded given that these are solved problems.
Then solve the problem I put before you.
> Why can't we have a standardized generic bytecode and VMs to run it?
And why stop there! There are plenty of "languages" that currently compile into HTML and CSS (like HAML and SASS for example). If we have a common VM for scripting then why not a common VM for HTML and CSS as well. Heck, we could do this all with a single VM and a common API. For backwards compatibility, we could use a new HTML tag to enable this VM. Furthermore, as a proof of concept, you could design a plugin for all the major browsers that implements this.
The browsers themselves are already built and powered using JS. Maintaining a comprehensive API at the speed that web tech advances in more than one client-side scripting language would be hellish -- browser vendors already have enough trouble agreeing on CSS and JS standards. The Stack Overflow article already raised a number of good reasons why not. Not sure why this is garnering so much attention from HN.
You're talking language syntax. Although it matters, it practically doesn't. People build stuff no matter what the language looks like. Look at Obj-C, that thing is horrid (syntax-wise) but look at all the developer adoption.
What is bad for innovation is to move back to the 90's where people had to handle local instances of applications, fix versioning problems, and have to install something just because they want one small piece of functionality.
It seems pretty reasonable to observe the desktop world, though, since it has the properties under discussion, and ask ourselves whether it's easier to deploy an application to a wide audience there or on the web.
I don't think you can dismiss someones dislike for a language as "they don't know how to use it". Common, many people have been building applications on client and server for 15+ years using JS and whatever exists on the backend. And 90% of the time, the backend language is better, and has way better tooling.
So you can understand and master JS (including prototypical programming) and still hate it.
I think the various Mozilla projects actually do have facilities for this, and that some significant portion of the chrome is done this way.
Where browser UIs aren't done this way, though, I suspect it's because the APIs are for components that aren't markup based -- you write the software for the platform with the APIs it provides, or (as I believe Mozilla has done) you write your own platform on top of something else.
I think the real question to ask yourself is -- if the conventional patterns of the desktop API that we'd more or less laid down by the mid 90s were so generally awesome, why didn't some universal client based on them take off instead of the web?
It's not as if we didn't have network aware desktop-style clients at the time...
I think we are asking opposite questions - if web based UI's are so awesome and have no caveats attached for display based apps then why are browsers not written using HTML, CSS and JS ? I am asking this question because I know at least one person from mozilla has replied to this thread.
"why didn't some universal client based on them take off instead of the web?"
Because you had several companies all fighting to have their desktop platform be the standard. The web slipped in the back door because nobody felt threatened by a hyperlink document publishing system. As such, it was the only platform that was available everywhere. Worse is better.
Interestingly, the web is starting to adopt the old desktop model. If you look at many of the emerging frameworks for web development (talking client side here), they all seem to be loosely based on the work of OpenStep.
It is actually a really great question posed by dman. If the web is suitable for applications, the browser chrome should be one of those such applications.
One point not in the existing comments is the event driven nature of the browser - even if you're eventually able to have good support for other runtimes in the browser (e.g., you can use Python via the Native Client plugin) most of them have such a large existing codebase of blocking code that I think you'd run into a lot of the same issues that you do now with Ruby & EventMachine, or Python & Twisted.
Similarly, if you were to put Python or Ruby in the browser you would necessarily need them to have some sort of DOM APIs (or there wouldn't be very much they could do in the browser). Those DOM APIs would once again be written in an event-based way.
"no big existing libraries of blocking code" (for js) just translates to "no big existing libraries", period.
A byetcode/VM approach would be an improvement on the web client. This has been used successfully for 10+ years on the server (JVM, CLR), so why not learn from things and advance the state of web development.
I don't understand why people defend JS so passionately. It was build in like 2 weeks, wasn't designed to build large complex applications, and hasn't really advanced at all since its inception. There are better options out there and the web development community should welcome any improvements to close the gap from Native to web.
While not exactly what the OP is calling for, this is interesting nonetheless, and it does provide a mechanism for using at least one other language in the browser, even if it uses JS as the platform, rather than natively supported.
It's justified. The site is used for problem solving.
Here the problem isn't the asker's, it can't be meaningfully solved by anyone on the site, and it is a matter of opinion whether any answer comes closer to solving it, or that there is a problem at all.
> You should only ask practical, answerable questions based on actual problems that you face. Chatty, open-ended questions diminish the usefulness of our site and push other questions off the front page.
The ability to decide what Stack Overflow is and isn't is what makes it a community, and not a jumble like Yahoo Answers.
And the specifics of closing questions don't have the violence of Wikipedia deletions. I don't approve of deleting user-contributed content, especially when it takes effort to build; closing on SO removes linking to the question, adds a little explanatory blurb, and diverts new attention away from the question. It doesn't destroy user contributions.
Now you (and the site's rules) are just getting pedantic.
What's the legal definition of a "Chatty, open-ended question" or a "practicable, answerable question"? No question is un-answerable or impracticable imho.
Those are some very ridiculous requirements if you ask me, and 300 odd other people who voted in favor of this question and it's answers.
P.S. in the midst of all this argument... CasperOne has added and removed his vote of no confidence for this question. It is now "closed as not constructive by Tim Cooper, lwburk, Tobu, 一二三, Graviton 8 hours ago". So which is it then?
Not everything is subjective. Stack Overflow has a stated purpose, and that purpose is not "whatever the most people feel like disussing." The Internet has proven that cats and politics will win that one every time.
The topic in question is not so far removed from the site's purpose to deem that it's "whatever the most people feel like discussing".
You are correct in that somebody must draw some kind of line somewhere in the sand... but I believe that Somebody jumped the gun on this one, as they have on many of my questions to similar websites in the past.
I think it's more of an elitist thing. "I know the exact rules better than you know the exact rules."
When a user needs to know and abide by every rule of every website on the net, the internet is immediately less interesting.
You referred to the number of votes the post got. I was saying that's a red herring. Given a choice between a great question about the theoretical underpinnings and practical applications of a feature in Clojure 1.4 and a picture of a cat in front of a computer, several orders of magnitude more people would vote for the cat than the programming question. This is why getting a lot of votes doesn't really prove relevance.
As for "I know the exact rules better than you know the exact rules": I don't see that at all. The rules are pretty simple. Here's a summary — if you follow it, you will not get your question locked:
1. Is it about programming?
2. Is it possible to give an objectively correct answer?
3. Is it stated politely?
In the particular case of this question, it doesn't even try to follow #2. It's an interesting question, I agree, but there's no right answer, so it's not a good Stack Overflow question. S:N ratio is extremely important on a site like Stack Overflow (because the people who answer questions well lose interest fast when they can't find good questions to answer, and vice-versa), so it is important to make sure that the site sticks closely to its purpose.
Incidentally, this isn't true of Wikipedia. Some of its rules make the site better, but a lot of the rules exist more for their own sake than because not following them would ruin the site (e.g. an article that's just descriptions of Pokemon episodes is pretty useless, but it doesn't make the article on Afghanistan less useful).
I'm also annoyed by the overly eager closing, but in this case I think it's justified: it's a relatively argumentative question with no real answer. The goal behind StackOverflow is to be something vaguely like interactive documentation for all of programming, so something like this doesn't really fit in. I imagine it might fit better with a site like programmers.stackexchange.com.
Language preference aside, the fact that no language has good support in the browser, the server and stand-alone totally baffles me.
I do wonder about this. I don't think the challenge of the task is the only answer. I think - guess - the rest of the answer might be that in practice, most developers focus on one of those, maybe two (most probably server and browser), rarely the three of them. I know first hand that some do work on the three, but they must be rare, seeing the interest in this. Maybe the momentum of the app stores bringing web devs to work on apps could gradually make people more aware of the benefits of having a universal language. Don't get me wrong, I enjoy the variety of languages, but I would be very happy to be able to focus and become proficient at one only language, even if that means giving up on some language specific advantages.
It's based on IronPython/IronRuby/DLR. I've been to a few PyCons and the CPython-based developers never seemed all that interested in it due to library support, and the majority of work happening on UNIX platforms. At the same time .NET developers didn't know what to do with this great set of tools.
JS has lots and lots of fundametal issues. Weird OO implementation (argue all you want but prototype inheritance is not what the prevailing wisdom is on how to do OO), no type system (at least give the option!), no packages/modules, no generics.
Don't people want dev tools to better help them building and refactoring web code? Web dev is like 15 years behind server development.
Of course some of these things are being fixed (e.g. modules are being added; there has been talk of optional types). At least when Google or Microsoft aren't dragging their feet and sabotaging the process.
As for generics, I'm not sure what you're looking for there; it's pretty simple to write generic functions in JS, or indeed any language with duck typing, no?
If Python uses indentation rather than curly braces or keywords, then it would not allow for minimization or obfuscation when used in the browser. This is the main reason IMO Google chose to design Dart with curly braces.