Hacker News Reader

Comment by xuejie | Hacker News Reader

This is exactly what I thought as well. Julia is born for this use case.

Except for the 1-indexing part.

Been wanting to try Julia out for a while, but the 1-based indexing is perennially putting me off. I can't see how I can avoid spending a large chunk of time (and endless frustration) unlearning years of 0-index muscle memory (nor I see why should I, for the sake of adapting to a single language that, at least initially, I will be just toying with).

It was probably a good marketing move on their part, a wink towards the Fortran/Matlab crowd, but it certainly damages the language's appeal for potential converts from C, C++ and Python.

Then challenge yourself to write some code completely agnostic to the indexing, which will force you to learn some neat features. Doing pointer arithmetic with your bare hands (however much muscle memory they have) is very seldom necessary, computers are pretty good at that stuff.

I thought one of Julia's compelling features is the ability drop down to the level of index arithmetics without losing performance (as Python does, once you start writing manual for loops).

If I want to stick with higher-level construct for dealing with "collections of numbers", I can use numpy arrays in Python, the STL in C++, etc.

Do you think Julia's high-level constructs are much better than the competition? E.g., how do they compare with C++20 ranges?

You can do some pretty interesting things with indexing in Julia: https://julialang.org/blog/2016/02/iteration

Maybe I phrased that poorly: you can indeed write the loops yourself (without a speed penalty) as advertised, to do things which are hard/ugly/impossible in numpy. But very often you can do this without dropping all the way down to explicit pointer arithmetic, where you'd have to care about base-0/1 and off-by-one errors (again without penalty). This in-between zone is what I was trying to suggest is worth exploring. See for example https://julialang.org/blog/2016/02/iteration for a taste.

Someone more polyglot than I am will have to comment on C++ comparisons.

It's not that bad in practice. I wrote Matlab for 12-years and Python for 15-years and seamlessly switch between 0 and 1 indexing.

I know the arguments for 0 vs 1 indexing, but in practice it's not really an issue since they're both just book-keeping. The only time where things might get interesting is for certain complex recursive expressions (recursive in the mathematical sense) where you want your code to match the equations, but in those cases I just create a new offset-index and work off that. (edit: just learned from another comment that Julia supports custom indices.)

Note: caveat -- my use of indices is mathematical. I don't do any kind of low-level stuff.

I mean, how much time are we really talking about here?

You can use any indexing scheme you like now.

Arrays can start at [-100] if you feel like it.

https://docs.julialang.org/en/v1/devdocs/offset-arrays/

LoL. It's 2019. There's no reason why start index should be fixed... Treat arrays as optimised hashmaps, and let users pick a default!

Edit: ah, a sibling comment (now deleted) mentions Julia does have some support for arbitrary indices ("offset arrays").

https://docs.julialang.org/en/v1/devdocs/offset-arrays/

sigh: this doesn't matter, this is a library provided feature not a language feature (like Ada) so if you try to use something else than 1-based array you'll find lots of incompatible libraries..

I didn't use offset arrays, but I don't expect lots of incompatible libraries if they implemented the proper array interfaces. Julia has duck typing, and thanks to multiple dispatch they can just specialize the few relevant methods that actually use the new type special properties.

Many of the most used Julia types are defined outside of the standard library, such as StaticArrays (for fixed size arrays) and CUArray (for GPU processing).

Reply on news.ycombinator.com