> Well - this comment is quite interesting. The parent one looks like a one-line "meh" comment. I'm quite happy to downvote the original and upvote this one...
The original title is a stupid flame-bait and the funny thing is it's a dated argument. [That was my point, turning the flame back.]
> There's a big difference though: afaik there's no real library for ecmascript that would integrate it with the os. There's simply no way to use ecmascript standalone on a typical system.
What are you talking about? There have been people working with Spidermonkey for ages. Now there are so many V8-based projects it feels almost like a crazy fad. The hello world example of V8 is a shell showing trivial OS integration.
> Once someone produces a serious repl-like environment and a set of sys / os / file libraries - it can compete with python.
There are plenty of libraries in the making, perhaps the criticism could be there are too many. The thing is, since it's trivial to interface it with C and C++, at the moment most (?) of us are just exploiting the much, much larger library base of those languages.
Use whatever language you feel like. In a few years, remember this. I might be wrong, or Python might get its act together, we don't really know. But the writing...
Well... I think I'll refer to what you wrote as lisp/perl6 syndrome :)
There is no lisp and there is no perl6. There is no ecmascript. There is some v8, rakudo, drscheme and others... It cannot compete with python, ruby and the rest. If you tell me that "ecmascript can be a standalone scripting tool", people will expect that you can run `ecmascript somefile` and make it just work. I heard about spidermonkey in mozilla and v8 in chrome of course - never heard that they can run standalone - it might be surprising to people involved in the project, but others?...
I meant the sys / os / file library, not some collection. If it's external to the language itself... sorry - but that's not good enough for "general purpose". If you say there are too many system libraries, then maybe you're right. C has stdlib, python has standard modules, ruby has standard modules, java has standard runtime environment - I see a trend here. If it's not obvious which ecmascript am I supposed to use and I cannot just download it and open a file with 1 line of code... sorry - it's not general purpose enough for most of my needs.
The community itself is kind of closed too. http://www.ecmascript.org/ doesn't lead anywhere interesting. Even the community page / wiki doesn't give me any interesting information. "This is a wiki for the ongoing specification work of Ecma TC39...." - thank you, but that's not what I'm looking for. We're "safe" from ecmascript for some time - at least until the people involved figure out how to introduce new people to the language.
The original title is a stupid flame-bait and the funny thing is it's a dated argument. [That was my point, turning the flame back.]
> There's a big difference though: afaik there's no real library for ecmascript that would integrate it with the os. There's simply no way to use ecmascript standalone on a typical system.
What are you talking about? There have been people working with Spidermonkey for ages. Now there are so many V8-based projects it feels almost like a crazy fad. The hello world example of V8 is a shell showing trivial OS integration.
> Once someone produces a serious repl-like environment and a set of sys / os / file libraries - it can compete with python.
There are plenty of libraries in the making, perhaps the criticism could be there are too many. The thing is, since it's trivial to interface it with C and C++, at the moment most (?) of us are just exploiting the much, much larger library base of those languages.
Use whatever language you feel like. In a few years, remember this. I might be wrong, or Python might get its act together, we don't really know. But the writing...