4 ms·

I recently read this paper about Julia (http://arxiv.org/abs/1411.1607 http://arxiv.org/abs/1411.1607). Now when I hear about PyPy I can't help but think about

I recently read this paper about Julia (http://arxiv.org/abs/1411.1607 http://arxiv.org/abs/1411.1607). Now when I hear about PyPy I can't help but think about this quote from that paper: New users also want a quick explanation as to why Julia is fast, and whether somehow the same “magic dust” could also be sprinkled on their traditional scientific computing language. [...] Julia is fast because we, the designers, developed it that way for us, the users. Performance is fragile, like accuracy, one arithmetic error can ruin an entire otherwise correct computation. We do not believe that a language can be designed for the human, and retrofitted for the computer. Rather a language must be designed from the start for the human and the computer. To me, Python and Ruby are both perfect examples of languages that were designed for the human, and ever since have seen extensive effort to retrofit them for fast execution by computers. I respect the work of the PyPy team, particularly given the raving reviews I've seen lately of how RPython is a boon to language designers who can use it to prototype their languages and get a decently-performing VM in not very much time: http://tratt.net/laurie/blog/entries/fast_enough_vms_in_fast_enough_time http://tratt.net/laurie/blog/entries/fast_enough_vms_in_fast... But I can't help but think that languages like Python and Ruby will start to fall to languages like Swift, Julia, Go, etc. that were designed with performance in mind. I'm not saying this will happen soon, but these languages are showing that you can have your cake and eat it too. I'm not sure how JavaScript and Lua fit into this analysis. They weren't specifically designed for performance, but have been very successfully optimized. Lua is a very simple language and Mike Pall is a genius, so LuaJIT has been very successful at speeding up Lua. JavaScript is a little more complicated, but has received an immense amount of resources into optimizing it, and has also been quite successful at getting fast.

tiffanyh 12y ago
Agreed. Where does Lua then fit into your analogy?
- justincormack 12y ago
  Lua was designed, and has things taken out, and has its semantics simplified (and well documented). And it is small.
aidenn0 12y ago
I will want to read that paper in the entirety later, but I think they are wrong. Many languages are now fast that were designed primarily, or even only for humans (see Lisp for the last one). Python is the language specification that is probably most impaired by performance on multi-core, due to the fact that threading semantics were so strongly specified. Pypy is now making a compelling argument that even that is not an insurmountable barrier. If by "retrofitted" they allow backwards-compatible changes to the languages in question (e.g. optional type annotations for dynamic languages) then I would estimate that a language not designed at all with performance in mind would suffer less than a 2x penalty given enough engineering effort.
nickbauman 12y ago
All languages other than pure machine code were designed for the humans first.
- _delirium 12y ago
  I don't think that's quite true. A lot of languages are a mix of designed-for-humans and designed-for-machine. They do aim to be higher-level than machine code, but it's quite common to have design decisions at least partly driven by considerations from the compiler side as well. Not necessarily only designing for efficient execution (though that is one); other design-for-machine considerations can include ease of parsing and ease of compiler implementation.
lucian1900 12y ago
LuaJIT, PyPy and the top JS runtimes are similarly fast nowadays.
Derbasti 12y ago
Python was designed to be a glue language. It does a terrific job at connecting together different pieces of C code. The more I use it, the more I realize that this is Python's calling. I envision a future where I code numerical stuff in Julia, and use Python to connect it to my main application, my GUI, web frontends and file juggling code.

tiffanyh 12y ago

Agreed. Where does Lua then fit into your analogy?

justincormack 12y ago
Lua was designed, and has things taken out, and has its semantics simplified (and well documented). And it is small.

aidenn0 12y ago

I will want to read that paper in the entirety later, but I think they are wrong. Many languages are now fast that were designed primarily, or even only for humans (see Lisp for the last one). Python is the language specification that is probably most impaired by performance on multi-core, due to the fact that threading semantics were so strongly specified. Pypy is now making a compelling argument that even that is not an insurmountable barrier. If by "retrofitted" they allow backwards-compatible changes to the languages in question (e.g. optional type annotations for dynamic languages) then I would estimate that a language not designed at all with performance in mind would suffer less than a 2x penalty given enough engineering effort.

nickbauman 12y ago

All languages other than pure machine code were designed for the humans first.

_delirium 12y ago
I don't think that's quite true. A lot of languages are a mix of designed-for-humans and designed-for-machine. They do aim to be higher-level than machine code, but it's quite common to have design decisions at least partly driven by considerations from the compiler side as well. Not necessarily only designing for efficient execution (though that is one); other design-for-machine considerations can include ease of parsing and ease of compiler implementation.

lucian1900 12y ago

LuaJIT, PyPy and the top JS runtimes are similarly fast nowadays.

Derbasti 12y ago

Python was designed to be a glue language. It does a terrific job at connecting together different pieces of C code. The more I use it, the more I realize that this is Python's calling. I envision a future where I code numerical stuff in Julia, and use Python to connect it to my main application, my GUI, web frontends and file juggling code.