[jfaucett]

"I really, really wish they had dropped the 1-based indexing and <= upper bound on index ranges."

really? There are quite a few things I don't like about julia, but using 1-indexing and "end" makes implementing algorithms much clearer IMHO.

The main pain points for me in julia are the module/pkg system and that the runtime is not just batteries but more like 10 generators included i.e. it could be way more minimal. But I get that the goal is to have a powerful scientific computing language and not to build a multipurpose language that emphasizes modular construction of code units and production ready package and build management utilities.

All in all, when judged by how well julia achieves its self-stated goals, I think it is excellent.

[halflings]

This is kind of bike-shedding (since that's such a small part of the language), but I also think there are arguments for using 0-indexing with open upper bounds.

Guido explains his choice best:

https://plus.google.com/115212051037621986145/posts/YTUxbXYZ...

[rbehrends]

Well, Julia is a language designed for mathematics, where indices starting at 1 is common (vectors, matrices). You can argue that polynomials have exponents starting at zero, but then you quickly get to Laurent polynomials, and what you really should be arguing is that the lower bound should be configurable, rather than being set at one specific value (which, of course, is still possible with custom types).

Second, I don't find Guido's argument convincing. Yes, half-open ranges can be mathematically more elegant (and that's actually Dijkstra's argument), but that doesn't mean that the code necessarily becomes more readable. For example, to construct an array without the element at index i, you'd do the following with Python-style indexing:

  a[0:i] + a[i+1:n]

and the following with closed intervals and indexing starting at 1:

  a[1:i-1] + a[i+1:n]

While there is an element of subjectivity to it, I at least find the latter option more readable (possibly because of habituation to mathematical notation).

While the notation for the specific example of i:i+k-1 might be less elegant with closed ranges, closed ranges are something that you find in every math textbook, because sums, products, unions, intersections from a to b (and other operators in that style) operate on closed ranges normally. Closed ranges are the norm in conventional mathematical notation and it makes sense to pick the option that minimizes the overhead when transcribing between mathematical texts and code.

[blt]

Here are some tasks that are ugly with [1:n] indexing:

    - the 1D index of element (i,j) in a matrix is i+(j-1)*m instead of i+j*m

    - the i'th 3-element subvector of a vector is v[3*(i-1)+1:3*i] 
      instead of v[3*i:3*(i+1)]

    - if you have vector of indices that partitions an vector into chunks,
      the i'th chunk is v[ind[i]:ind[i+1]-1] instead of v[ind[i]:ind[i+1]]

Perhaps small issues, but these are all real examples from my most recent Matlab project that were annoying.

But maybe, like the static typing issue, my opinion on this topic is distorted because I spent a lot of time programming in C++ and comparatively little time reading math papers.

Or maybe it would be equally easy to make a list of tasks that are ugly with [0:n) indexing.

[jasode]

>I really, really wish they had dropped the 1-based indexing

>, my opinion on this topic is distorted because I spent a lot of time programming in C++

Mathematics-related programming[1] in MATLAB, R Language, Mathematica, SAS, etc all use 1-based indexing. Given that the originators of Julia are MATLAB users, it makes sense that they made a deliberate choice to keep 1-based indexing.

In other words, it was more important to grab mindshare from those previous math tools rather than appeal to C/C++/Java/etc programmers.

One outlier in the landscape of numerical programming is Python+NumPy/SciPy in the sense that it uses 0-based indices. While Julia also wants to be attractive to Python programmers, it still seems like the bigger motivation was programmers of MATLAB and other math software.

[1]https://www.youtube.com/watch?v=02U9AJMEWx0&feature=youtu.be...

[Fomite]

This, pretty much. Not to mention that, beyond languages, data is often 1-based indexed. I have never gotten a patient data set with ID=0 as the first entry. In my mind, compatibility with what users are expecting, and trying not to induce indexing errors, trumps most other concerns.

[jasode]

>, beyond languages, data is often 1-based indexed.

That's a good point. Probably the most widespread data example for non-programmers is spreadsheets (MS Excel, Google Sheets). The first row[1] in the spreadsheet is labeled as "1" instead of "0". The idiomatic Visual Basic programming code to loop through the rows would look something like:

  For Each cell In Range("a1:a25")  ' not "a0:a24"
      ' do work
  Next cell

[1]https://www.google.com/search?q=microsoft+excel+spreadsheet+...

[cohomologo]

Mathematica is actually 0-based - but with the zero index spot reserved. A list {1, 2, 3}=List[1, 2, 3] could be read as (List 1 2 3) in Lisp style; one can check if you have Mathematica that {1, 2, 3}[[0]] = List.

But I think that's neither here nor there. Whenever the index has more use than as a label, mathematics starts at zero. Modular arithmetic, polynomials, discrete fourier transformations - for that matter, any discrete approximation of continuous math - all naturally start at zero, and generate lots of -1s in one-based indexing.

[jasode]

In this subthread, the phrase "0-based / 1-based" is for the word "base" accessing the first element which is semantically equivalent to x[0] in C/C++/Python/etc or x[1] in R Language. Yes in Mathematica, putting "0" between "[" "]" will get you the reserved "head" but that's not how people are talking about "0-based" here.

[rbehrends]

You will find problematic examples no matter which option you choose (which is why I personally favor being able to set the lower bound freely).

With half-open ranges, for example, you will need different code to address a segment and the last element of a segment. E.g. if you have some structure with start_of(i) and end_of(i) expressions, then you can do a[start_of(i):end_of(i)] with closed indexing and a[end_of(i)] to access the last element, while with open intervals, you have to break the abstraction and use a[end_of(i)-1].

You can also iterate over start_of(i) .. end_of(i) in a for loop naturally if ranges are closed. (See how Python's iteration is defined in terms of half-open ranges and how iterating over closed ranges – which happens often enough when the values aren't indices – is a bit of a pain in Python.)

[ihnorton]

See https://github.com/eschnett/FlexibleArrays.jl

(somewhat in jest, there's also https://github.com/simonster/TwoBasedIndexing.jl)

[exDM69]

From the comments section of that G+ post I found this Dijkstra essay with really good arguments for zero-based indexing.

Not only does it have sound mathematical reasoning but also some anecdotal evidence of problems caused by one-based indexing in programming languages.

http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF

[baldfat]

For statistics 1 based is much cleaner and less error prone in my opinion. R is 1 based and it drives me nuts to have to switch to Pandas.

[blt]

the 10 generators are critical if it's going to supplant Matlab. one of the biggest selling points for Matlab is that you don't have to spend a bunch of time searching for libraries, installing, configuring, matching versions, etc. You just spend a bunch of money on Toolboxes instead.