3 ms·

Hello, (former) fellow python fans. ECMAScript, formerly known as JavaScript, is doing very well. So well Python developers started to show their concern for ab

by alecco 17y ago

Hello, (former) fellow python fans. ECMAScript, formerly known as JavaScript, is doing very well. So well Python developers started to show their concern for about 2 years. You could read it on PyPy blog and Python mailing lists. The new ECMAScript VMs are getting faster and already beating Python's. And they are getting faster with plenty of room to improve. The language is cleaning up, with a major milestone reached a few days ago. They have the biggest installed base in the world and there are more developers. The language fits in precisely the same slot as Python. The writing is on the wall. Down-voting what you don't like doesn't make it go away and it should be very un-HN. EDIT: Read again the name of the story title if you think my post was flame-bait.

viraptor 17y ago
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... But is it really killing python? The language is basically the same (almost-dictionary based, easily extensible types / prototypes, etc.). 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. ecmascript is good in places where you need an embedded scripting language, but lua is not enough. Unfortunately neither of them is useful as a general-purpose language right now. Once someone produces a serious repl-like environment and a set of sys / os / file libraries - it can compete with python.
- alecco 17y ago
  > 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...
  - viraptor 17y ago
    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/ 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.
- cema 17y ago
  I agree with the library argument and the GPL argument. And I agree that it is unfortunate these two languages (Lua and ECMAScript) do not have a complete standalone environment at this point. I disagree with the downmod argument: the one-liner did not feel as a "meh" argument but a succinct reference to an easily (re)constructed (but more verbose) argument regarding ECMASCript versus Python similar to the original argument of Python versus Lisp. I think such succinct arguments are fine here (in fact, I have upmodded it to compensate for what I considered the undeserved negative score).
  - silentbicycle 17y ago
    In what sense does Lua not have a standalone environment? That's news to me. $ lua Lua 5.1.4 Copyright (C) 1994-2008 Lua.org, PUC-Rio >
    - kzh 17y ago
      Same for javascript... I use the js console all the time. Thank you, spidermonkey.
- silentbicycle 17y ago
  > but lua is not enough. Unfortunately neither of them is useful as a general-purpose language right now. I emphatically disagree. Lua is a great language, it just expects you to be comfortable with more than one language (ideally including C). It's a scripting language, in a more literal sense than, say, Python - you use it to glue together libraries in several other languages and give them a simple repl and scripting interface. It also seems to be a lot less "opinionated" than Python (let alone Haskell) -- since the whole design of the language is skewed towards being embedded in something else, it's quite happy to be used in just the parts where it's the best tool for the job, and otherwise stay out of the way, and it doesn't come with its own heavy style requirements.
mcav 17y ago
If Javascript obtains a standard library as comprehensive as Python's, then yes, Python would be in a tough spot. That is not currently the case.
sreque 17y ago
Neither javascript or python or fast enough to matter. Look at the alioth tests (http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=all&box=1 http://shootout.alioth.debian.org/u32q/benchmark.php?test=al...). V8 is still 25 times slower than C. Does it really matter if you're 25 times slower than C vs 50 or 60 times slower? No, not at all. Using either on the server side you'd have to resort to native code to do the real heavy lifting. Plus, if unladen swallow keeps its promise of doubling CPython's speed, then the gap between the two languages will once again be fairly narrow. There are more client-side Javascript developers than Python developers, maybe, but not more server-side or general purpose Javascript developers. Google's primary server-side languages are C++, Java, and Python, by the way. Plus, as a language, Python is superior to Javascript. While the best languages rarely win, hopefully it'll help keep Python in the game for a while longer!
- alecco 17y ago
  My point was that Python isn't killing Lisp any more than ECMAScript is killing Python. About the rest, I answered in other parts of this thread.

by alecco 17y ago

viraptor 17y ago

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... But is it really killing python? The language is basically the same (almost-dictionary based, easily extensible types / prototypes, etc.). 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. ecmascript is good in places where you need an embedded scripting language, but lua is not enough. Unfortunately neither of them is useful as a general-purpose language right now. Once someone produces a serious repl-like environment and a set of sys / os / file libraries - it can compete with python.

alecco 17y ago
> 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...
- viraptor 17y ago
  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/ 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.
cema 17y ago
I agree with the library argument and the GPL argument. And I agree that it is unfortunate these two languages (Lua and ECMAScript) do not have a complete standalone environment at this point. I disagree with the downmod argument: the one-liner did not feel as a "meh" argument but a succinct reference to an easily (re)constructed (but more verbose) argument regarding ECMASCript versus Python similar to the original argument of Python versus Lisp. I think such succinct arguments are fine here (in fact, I have upmodded it to compensate for what I considered the undeserved negative score).
- silentbicycle 17y ago
  In what sense does Lua not have a standalone environment? That's news to me. $ lua Lua 5.1.4 Copyright (C) 1994-2008 Lua.org, PUC-Rio >
  - kzh 17y ago
    Same for javascript... I use the js console all the time. Thank you, spidermonkey.
silentbicycle 17y ago
> but lua is not enough. Unfortunately neither of them is useful as a general-purpose language right now. I emphatically disagree. Lua is a great language, it just expects you to be comfortable with more than one language (ideally including C). It's a scripting language, in a more literal sense than, say, Python - you use it to glue together libraries in several other languages and give them a simple repl and scripting interface. It also seems to be a lot less "opinionated" than Python (let alone Haskell) -- since the whole design of the language is skewed towards being embedded in something else, it's quite happy to be used in just the parts where it's the best tool for the job, and otherwise stay out of the way, and it doesn't come with its own heavy style requirements.

mcav 17y ago

If Javascript obtains a standard library as comprehensive as Python's, then yes, Python would be in a tough spot. That is not currently the case.

sreque 17y ago

Neither javascript or python or fast enough to matter. Look at the alioth tests (http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=all&box=1 http://shootout.alioth.debian.org/u32q/benchmark.php?test=al...). V8 is still 25 times slower than C. Does it really matter if you're 25 times slower than C vs 50 or 60 times slower? No, not at all. Using either on the server side you'd have to resort to native code to do the real heavy lifting. Plus, if unladen swallow keeps its promise of doubling CPython's speed, then the gap between the two languages will once again be fairly narrow. There are more client-side Javascript developers than Python developers, maybe, but not more server-side or general purpose Javascript developers. Google's primary server-side languages are C++, Java, and Python, by the way. Plus, as a language, Python is superior to Javascript. While the best languages rarely win, hopefully it'll help keep Python in the game for a while longer!

alecco 17y ago
My point was that Python isn't killing Lisp any more than ECMAScript is killing Python. About the rest, I answered in other parts of this thread.