PythonJS now faster than CPython
pythonjs.blogspot.com
pythonjs.blogspot.com
If so I will be impressed. Glancing over the code, it looks pretty short, and I can imagine benchmarks will run, but not real programs.
https://github.com/PythonJS/PythonJS/blob/master/pythonjs/py...
It's true that most programs don't use all the dynamism of Python, but they probably depend on something that does (e.g. Django). Python is more dynamic than JavaScript, in that it has __getattr__, __setattr__, __getitem__, etc.
If not, it's not fair to compare it to PyPy... PyPy actually runs arbitrary Python programs.
No, it's not. You can do equivalents to all of those in Javascript. Javascript objects are all mutable with a few exceptions. They are just maps of properties, very similar to Python's. Properties can be added or changed at runtime.
For example, setattr(obj, item, value) in python is basically just obj[item] = value in js.
JavaScript is in the process of getting similar capabilities with Harmony proxies, but the spec has yet to be finalized: http://wiki.ecmascript.org/doku.php?id=harmony:direct_proxie...
Harmony proxies catch everything, and really overload the getter/setter mechanism.
So...
> var x = {}
> Object.defineProperty(x, 'value', { get: function() { return 1 }, set: function() { console.log('set') } })
> x.value
1
> x.value = 2
set
> x.value
1obj[name] works if you have already either assigned a value for that name, it exists in the prototype chain, or you have defined a getter via Object.defineProperty(). It's truly no different than obj.name[1] - `name` has to already exist in some form.
Python's __getattr__ [2] takes the attribute name as an argument, so it can be used to implement property access for any name, even those not known ahead of time.
Ruby has something similar with method_missing, and even more with define_method and instance_eval. Dart has noSuchMethod.
These are possible to implement in compile-to-JS language, but tricky to make fast. Dart's static analysis looks for all names that could be called on objects with a noSuchMethod, tries to figure out the most specific class it can add them to, then adds stubs to the JS prototypes to redirect to noSuchMethod(). A compile-to-JS Ruby could implement define_method easily enough, but method_missing is would be impossible to do the way Dart does it due to the open classes: you could dynamically add method_missing and not have the stubs available. If you want full Ruby semantics you have to abstract away method calls, which will be slow. I'm guessing the same problem exists for Python, so I wonder the same thing as the grandparent post: did they implement __getattr__ fully?
[1] With the small difference in the names that are allowed. [2] https://docs.python.org/3/reference/datamodel.html#object.__...
https://github.com/PythonJS/PythonJS/blob/master/regtests/cl...
__getattr__ and __getattribute__ are implemented in the special __get__ function defined in: https://github.com/PythonJS/PythonJS/blob/master/pythonjs/ru...
However, you can already hack them in and there are multiple js projects that let you compile ES6 down to ES5, proxies included.
As other commenters noted, python is not "more dynamic" than javascript. You can easily transform python code that does unusual metaprogramming stuff to javascript code that does similar metaprogramming stuff but looks significantly different; basically all languages that support runtime-eval will let you imitate all other metaprogramming features in a somewhat verbose fashion.
[0]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
Of course, but will it still be as fast? For example we can trivially turn a Python expression "a + b" into a Javascript expression "a + b" to get a great speed benefit. It may even give correct results in benchmarks, but in general it breaks the semantics and therefore any frameworks which rely on it.
FYI in Python "a + b" is equivalent to "a.__add__(b)", and hence the correct Javascript would look more like "a.__add__(b)", but this requires a property lookup and a function call so a lot of the speed gains may be lost (although some benefits may be regained by JITting).
Considering that the parent pointed out how small this project's codebase is, it does give legitimate concern about how many rules there are for mapping Python's semantics to Javascript's. For example, the ShedSkin project has been around for years and gets very impressive benchmark results since it compiles Python to C++; however, it tries to map Python classes directly to C++ classes, which breaks the semantics immensely.
https://github.com/PythonJS/PythonJS/blob/master/pythonjs/py...
(As it happens, my interpreter can only run a single fixed program, but I'm not worried: most people won't read past the headline when I announce it.)
That's great!
Even if your new interpreter doesn't run all the code that's out there it can serve as a base for further work, it's a nice proof of concept and it's just plain cool hacking. It certainly beats all those people merely posting snarky comments on project announcements.
>(As it happens, my interpreter can only run a single fixed program, but I'm not worried: most people won't read past the headline when I announce it.)
With sarcasm off now, yeah?
They worked on something and they are enthusiastic about the results they get. Perhaps they want to oversell them, in a headline. So what? If people "won't read past the headline" then they also won't be using this PythonJS. So no harm done to them.
At worst, you'll be lured to read an interesting article. And if you have any understanding of compilers/interpreters at all, you'll know before the end of it who real-world-usable it would be or not.
Don't know why, don't know why it's FUD, etc. Next time when they get a choice, they'll bash CPython. Not figuring why everyone uses CPython probably.
And you're encouraging that. Probably just thinking it puts you on a higher pedestal or something of the sort. I think its pretty shitty.
The damaging thing is claiming things like PythonJS are implementations of Python, when they merely share syntax and some semantics. They might be fast, but that's not very relevant.
Runtimes like PyPy is where we should be looking, since they implement the full Python language and are fast.
Compared to what? Please be specific in your definition of "slow."
>Runtimes like PyPy is where we should be looking, since they implement the full Python language and are fast.
Why should 'we' be looking to PyPy? Have you run a non-trivial application with pypy (v. standard cpy) and found it to be significantly faster?
Even if your code would benefit from JIT, and your code is compatible for running on PyPy, does it benefit more from a compiler switch than CPython + Pandas?
Yes, I have run non-trivial applications on PyPy and they were significantly faster. Its only downside is libraries that depend on CPython extensions, but there are few of those left.
Pandas doesn't do much for removing function call overhead. I don't necessarily have large mathematical datasets, I just want my web service to be easier to write, by not having to care about what CPython is terribly slow at.
I could've manually inlined lots of functions to avoid the overhead on CPython, but I'd have a horrible code base. On PyPy I can simply not care about this aspect, just like in most other languages.
C most likely is, or at least more reliably. JS engines specialise to proper arrays most of the time, though. They're quite remarkably fast, much like PyPy.
CPython, the original Python interpreter written in C, is not particularly fast at anything.
Unlike PythonJS, it does not have the goal of being 100% Python compatible, but instead takes the CoffeeScript approach. So, like Coffeescript, you get (mostly) clean Javascript output, no huge library dependency, runs nearly as fast as Javascript, etc.
Check out the "ants" demo - http://salvatore.pythonanywhere.com/RapydBox/default/editor
I've been playing around with both PythonJS and Rapydscript, and I like both. Different goals. PythonJS can output to Lua, too - so there's the whole Python in LuaJIT angle which could be very interesting as it matures.
Something that I have learned about reading benchmarks is to pay attention to who is coming consistently second. Usually that is the most informative part of a benchmark.
Neat, but a more compelling post would compare with CoffeeScript and check build times, high-level syntax, and features like generators, list comprehensions, itertools, functools, and so on.
Edit: why the downvote? Am I incorrect about something? If so, I'm genuinely curious to know what I'm overlooking here.
Edit 2: I went over to the github page and it is in fact a 'transpiler', though it can run self-hosted in node, and the features list includes both list comprehensions and yield (i.e. generator functions). It looks like the itertools and functools libraries aren't supported yet, but doing so really wouldn't be too difficult. CoffeeScript is a direct output option too.
A lot of totally correct and perfectly valid commentary ends up getting downvoted these days, often with no attempt made to explain why. It's particularly likely to happen when members of the Mozilla, JavaScript or Rust communities are involved. They're particularly sensitive to anything that might contradict their beliefs, and apparently they're particularly eager to downvote, for whatever reason.
These days, many of us have started to read all of the downvoted comments. Aside from occasional spam, they're often among the most insightful comments in any given thread.
Your repetitive comments about Rust's instability almost always receive a lot of feedback about why they are incorrect and/or invalid.
In no way can Rust be considered "stable". The most recent version is 0.10 (that is, it's still very pre-1.0), it's undergoing significant breaking changes on an ongoing basis, and even its home page warns that "Rust is a work-in-progress and may do anything it likes up to and including eating your laundry."
Anyone who points out that Rust is just not stable yet is absolutely correct. Anyone who points out that it's looking unlikely that it will be stable before the promised end-of-2014 deadline for 1.0 is also correct.
It doesn't matter who points out these facts, or how many times they do so. The facts are still facts, and whoever expresses them is totally correct.
My suspicion is that the inappropriate downvoting is just immaturity on the part of the Rust developers. I realize that it can hurt to face valid criticism of one's work, but an important part of being a professional adult is to consider such criticism rationally, and to learn how to improve based upon it. Engaging in censorship of facts, however, completely contradicts with self-improvement.
It renders the voting system useless when it's incorrectly used to censor others, due to a lack of emotional control on the part of the person misusing the system.
It's one thing to downvote blatant commercial spam that has no inherent value. It's harmful to downvote perfectly legitimate commentary that you may just happen to disagree with, however.
If you feel the need to vote down perfectly legitimate comments merely expressing a truth that you dislike, so be it. I can't stop you, and the others you've chosen to target can't stop you, either. However, reality will be reality, regardless of the voting. Rust will still remain unstable no matter how many down arrows you click.
Stability isn't something that happens overnight. It takes a lot of discipline, and this discipline has to be ingrained within the very project itself. I don't see this as the case with Rust.
This is a critical difference that ought to be called out, especially in the "add" micro-benchmark, which is measuring two very different things in the two implementations.
http://pythonjs.blogspot.com/2014/06/64bit-integer-long-type...
Hopefully this will slowly fix itself.
- Does X do all or at least most that Y does?
- Are the benchmarks sane? I.e. not the pointless arithmetic fibonacci that nobody really uses, but the useful stuff such as regexps etc.
Asides from that, this looks quite promising!