3 ms·

Aside from the fact that 1-based indexing is better for scientific code (see Fortran), I don’t think that it matters very often. I don’t think that any Julia pr

Aside from the fact that 1-based indexing is better for scientific code (see Fortran), I don’t think that it matters very often. I don’t think that any Julia program I’ve ever written would need to change if Julia adopted 0-based tomorrow. You don’t typically write C-style loops in Julia; you use array functions and operators, and if you need to iterate you write `for i in array ...`. If you really need the first or last element you write `a[begin]` or `a[end]`.

IshKebab 8mo ago
> the fact that 1-based indexing is better for scientific code (see Fortran) It really isn't. "Scientific code" isn't some separate thing. The only way it can help is if you're trying to write code that matches equations in a paper that uses 1-based indexing. But that very minor advantage doesn't outweigh the disadvantages by a wide margin. Lean doesn't make this silly mistake. > If you really need the first or last element What if you need the Nth block of M elements? The number of times I've written arr[(n-1)m+1:nm] in MATLAB... I do not know how anyone can prefer that nonsense to e.g. nm..<(n+1)m
- Certhas 8mo ago
  What if I want the nth element up to the math element? arr[n:m]. And if I want to split the array into two parts, one until the nth element and the other from the m+1st element arr[1:m] and arr[(m+1):end]. Julia matches how people speak about arrays, including C programmers in their comments. Arrays are (conceptually) not pointer arithmetic. Also for your usecase typically you would just use a 2d array and write a[n,:].
  - IshKebab 8mo ago
    > arr[n:m] arr[n..=m] > arr[1:m] and arr[(m+1):end] arr[0..m], arr[m..] Much nicer. > Arrays are (conceptually) not pointer arithmetic. Look at a ruler. Does it start at 1?
    - mbauman 8mo ago
      This is such a classic example of online discourse in general. There are two options, and folks tribally cling to one or the other without realizing that both are legitimate and well-suited for different situations. Yes, of course distances are measured starting from 0. But we count discrete things starting at 1. You can do mental gymnastics to enumerate from zero and many programmers are (unfortunately IMO) taught to do so. It's a hard thing to learn that way, so for the folks that have done so, it often becomes a point of pride and a shibboleth. As a classic example, a four story building has four floors. But you only need to go up three flights to get to the top. You can legitimately call the top floor either 3 or 4, and folks are similarly tribal about their own cultural norms around this one, too.
      - IshKebab 8mo ago
        > There are two options, and folks tribally cling to one or the other without realizing that both are legitimate and well-suited for different situations. No I disagree entirely. One is simply better. > It's a hard thing to learn that way, so for the folks that have done so, it often becomes a point of pride and a shibboleth. It is not hard. It's not better because it's hard-won knowledge. It's better because it leads to simpler, more elegant code. Simple as.
        mbauman 8mo ago
        Thanks for proving my point perfectly.
      - Certhas 8mo ago
        Fully agreed. I first struggled when switching from python to Julia, then ended up finding it slightly better for my use cases (which includes teaching scientists who are not programmers). But it's simply not a big deal either way. I am also reminded of the significant whitespace objections to python in the old days, before python took over everything...
    - minihoster 8mo ago
      > arr[n..=m] so you just need to overload the syntax of intervals even more to make it work > arr[0..m], arr[m..] now `m` refers to different things depending on which side of the interval it's on. less characters doesn't mean nicer I get it though, I was skeptical about 1-based indexing when I started Julia. By the nature of indices vs length there will always be an off-by-one problem: either you have elements [n, m - 1] with length (m - n) or [n, m] with length (m - n + 1). Unless you're doing a bunch of pointer arithmetic type stuff, I find the symmetry of a inclusive-inclusive interval to be a better default. As a final rebuttal I offer: range(n - 1, -1, -1)
- banku_brougham 8mo ago
  >It really isn't. They way people reveal themselves is a pattern worthy of taking note.
fc417fc802 8mo ago
> Aside from the fact that 1-based indexing is better for scientific code I find it to be substantially worse. It's fine as long as you don't manipulate the indicies. But as soon as you start doing math on them 1 based becomes a headache (at least IME). Meanwhile all you get in exchange (at least as far as I can tell) is ease of speaking about them in natural language. But I'm not usually conversing about indicies. Concise range notations are a mixed bag. There's pros and cons to either scheme there as far as the syntax goes.

IshKebab 8mo ago

> the fact that 1-based indexing is better for scientific code (see Fortran) It really isn't. "Scientific code" isn't some separate thing. The only way it can help is if you're trying to write code that matches equations in a paper that uses 1-based indexing. But that very minor advantage doesn't outweigh the disadvantages by a wide margin. Lean doesn't make this silly mistake. > If you really need the first or last element What if you need the Nth block of M elements? The number of times I've written arr[(n-1)m+1:nm] in MATLAB... I do not know how anyone can prefer that nonsense to e.g. nm..<(n+1)m

Certhas 8mo ago
What if I want the nth element up to the math element? arr[n:m]. And if I want to split the array into two parts, one until the nth element and the other from the m+1st element arr[1:m] and arr[(m+1):end]. Julia matches how people speak about arrays, including C programmers in their comments. Arrays are (conceptually) not pointer arithmetic. Also for your usecase typically you would just use a 2d array and write a[n,:].
- IshKebab 8mo ago
  > arr[n:m] arr[n..=m] > arr[1:m] and arr[(m+1):end] arr[0..m], arr[m..] Much nicer. > Arrays are (conceptually) not pointer arithmetic. Look at a ruler. Does it start at 1?
  - mbauman 8mo ago
    This is such a classic example of online discourse in general. There are two options, and folks tribally cling to one or the other without realizing that both are legitimate and well-suited for different situations. Yes, of course distances are measured starting from 0. But we count discrete things starting at 1. You can do mental gymnastics to enumerate from zero and many programmers are (unfortunately IMO) taught to do so. It's a hard thing to learn that way, so for the folks that have done so, it often becomes a point of pride and a shibboleth. As a classic example, a four story building has four floors. But you only need to go up three flights to get to the top. You can legitimately call the top floor either 3 or 4, and folks are similarly tribal about their own cultural norms around this one, too.
    - IshKebab 8mo ago
      > There are two options, and folks tribally cling to one or the other without realizing that both are legitimate and well-suited for different situations. No I disagree entirely. One is simply better. > It's a hard thing to learn that way, so for the folks that have done so, it often becomes a point of pride and a shibboleth. It is not hard. It's not better because it's hard-won knowledge. It's better because it leads to simpler, more elegant code. Simple as.
      - mbauman 8mo ago
        Thanks for proving my point perfectly.
    - Certhas 8mo ago
      Fully agreed. I first struggled when switching from python to Julia, then ended up finding it slightly better for my use cases (which includes teaching scientists who are not programmers). But it's simply not a big deal either way. I am also reminded of the significant whitespace objections to python in the old days, before python took over everything...
  - minihoster 8mo ago
    > arr[n..=m] so you just need to overload the syntax of intervals even more to make it work > arr[0..m], arr[m..] now `m` refers to different things depending on which side of the interval it's on. less characters doesn't mean nicer I get it though, I was skeptical about 1-based indexing when I started Julia. By the nature of indices vs length there will always be an off-by-one problem: either you have elements [n, m - 1] with length (m - n) or [n, m] with length (m - n + 1). Unless you're doing a bunch of pointer arithmetic type stuff, I find the symmetry of a inclusive-inclusive interval to be a better default. As a final rebuttal I offer: range(n - 1, -1, -1)
banku_brougham 8mo ago
>It really isn't. They way people reveal themselves is a pattern worthy of taking note.

fc417fc802 8mo ago

> Aside from the fact that 1-based indexing is better for scientific code I find it to be substantially worse. It's fine as long as you don't manipulate the indicies. But as soon as you start doing math on them 1 based becomes a headache (at least IME). Meanwhile all you get in exchange (at least as far as I can tell) is ease of speaking about them in natural language. But I'm not usually conversing about indicies. Concise range notations are a mixed bag. There's pros and cons to either scheme there as far as the syntax goes.