Hacker News Reader

Comment by JupiterMoon | Hacker News Reader

Looping over lists/arrays is not idiomatic Python.

The point of that benchmark is looping over lists or arrays. The benchmark verifies the well-known fact that straight Python is a lousy choice for those situations when you absolutely need to do this. Dropping into C extensions or some-of-the-language Numba would be a different comparison, and show a different result.

Did they at least attempt list comprehensions rather than loops?

EDIT Also in the scientific fields I've encountered not using the various libraries like numpy is non-idomatic. I personally think that python should absorb numpy into the standard library but effectively people I know treat it as if it were already there.

You can argue that numpy etc are implemented in C. But is the Julia interpretor not implemented in C?

Don't know whether list comprehensions were tried. Refactoring suggestions could be considered, if they still capture the main point of the benchmark.

Most of the Julia standard library is implemented in Julia.

There is no point benchmarking badly written language A vs well written language B. I actually find the Julia benchmarks misleading and that kind of thing leaves a bad taste.

Arguments about liking to loop over arrays to operate on them are a matter of taste. I like whole array operations, it's just what I learned first and best (Fortran 9x+ and numpy). Someone else may prefer to write loops (maybe they started doing numerical work with F77 or C). There is no universal correct way to express things -- but there is sometimes a language specific best way and to benchmark ignoring this is not good.

An astonishing amount of Julia is written in Julia.

Are they throwing away 40-50 years of work on things like LAPACK/BLAS? Or do they still build on the basic foundations and implement higher level things in Julia?

No --- I thought about adding that caveat but didn't. Most of the non-Julia code that I'm aware of is scientific libraries: linear algebra (LAPACK/BLAS), random number generators, etc. But lots of very basic foundations and data types are straight Julia --- array addition (as a very trivial example) is implemented by looping over the elements of the arrays in Julia, not by passing the loop to a C library.[1]

Reimplementing LAPACK or BLAS would be a lot of unnecessary work, but I think that one goal of the language is to be fast enough that a reimplementation would not be worse than the existing versions. (I'm not affiliated w/ the project, though, so I'm just guessing.)

[1]: https://github.com/JuliaLang/julia/blob/master/base/arraymat...

Interesting. Sensible. How possible/easy is it to use Julia libraries from e.g. python or R or C++?

There's an embedding API that's not too bad to work with. There are pyjulia and rjulia projects, but they're not quite as actively developed as the other directions of PyCall.jl or RCall.jl. Making standalone libraries out of Julia code isn't easy to do yet, but should eventually be better-supported.

You can use the up vote for that.

Reply on news.ycombinator.com