Comment by IshKebab

2 days ago

IMO it just had too many rough edges. Very slow compilation, correctness issues (https://yuri.is/not-julia/), kinda janky tooling (not nearly as bad as pip tbf). Even basic language mistakes like implicit variable declaration and 1-based indexing (in 2012??).

Yes 1-based indexing is a mistake. It leads to significantly less elegant code - especially for generic code - and is no harder to understand than 1-based indexing for people capable of programming. Fight me.

20 comments

IshKebab

TimorousBestie 2 days ago

Analogous to “time to first plot”, Julia metacommentary now has time to first “Why I no longer. . .” repost.

postflopclarity 2 days ago

I'm even sympathetic to some of the concerns. I say that as someone deeply embedded in the Julia community. but seeing this same repost over and over for years honestly starts to get pretty frustrating.

bouchard 2 days ago

> Yes 1-based indexing is a mistake. It leads to significantly less elegant code - especially for generic code - and is no harder to understand than 1-based indexing for people capable of programming.

Some would argue that 0-based indexing is significantly less elegant for numerical/scientific code, but that depends on whether they come from a MATLAB/Fortran or Python/C(++) background.

A decision was made to target the MATLAB/Fortran (and unhappy? Python/C++) crowd first, thus the choice of 1-based indexing and column-major order, but at the end of the day it's a matter of personal preference.

0-based indexing would have made it easier to reach a larger audience, however.

> and is no harder to understand than 1-based indexing for people capable of programming.

The same could be said the other way around ;-)

markkitti 2 days ago

The 0 or 1 based indexing is actually a very superficial debate for people not very familiar with Julia. Note that 1-based indexing is a standard library feature not inherent to the Julia language itself.

The real indexing issue is whether arbitrary-base abstraction is too easily available.

    # Correct, Vector is 1-based
    function mysum(v::Vector{T}) where {T <: Integer}
        s = zero(T)
        for i in 1:length(v)
            s += v[i]
        end
        return s
    end

    #Incorrect, AbstractVector is not necessarily one based
    function mysum(v::AbstractVector{T}) where {T <: Integer)
        s = zero(T)
        for i in 1:length(v)
            s += v[i]
        end
        return s
    end

    #Correct
    function mysum(v::AbstractVector{T}) where {T <: Integer)
        s = zero(T)
        for e in v
            s += e
        end
        return s
    end

Basically, the concrete `Vector` type is 1-based. However, `AbstractVector` is could have an arbitrary first index. OffsetArrays.jl is a non-standard package that provides the ability to create arrays with indexes that can start at an arbitrary point including 0.

leephillips 2 days ago
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 2 days 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
  
  10 replies →
- fc417fc802 2 days 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.
qsi 2 days ago

Heh. I grew up writing C code and had real trouble adapting to Matlab's 1-based indexing. Much later I tried Python and was constantly confused by 0-based indexing.
I don't think one is better than the other but my mind is currently wired to see indexing with base 1.
Then there's Option Base 1 in VBA if you don't like the default behavior. Perfect for creating subtle off-by-one bugs.

simondanisch 2 days ago

lol. There's not much to fight since its a very personal problem how you want to write code. It's evident that all the capable programmers in the Julia community, have found satisfactory ways to get around it, so if you haven't yet, I don't see how that's a Julia problem ;) I can only say I haven't had a single problem with one based indexing in 12 years of developing Julia code. I also haven't run into many correctness issues compared to other languages I've been using. I think Yuri also has been using lots of packages which haven't been very mature. How on earth can you compare a 10 years old library with lots of maintainers with packages created in one year by one person? That's at least what Yuri's critic boils down to me.

Certhas 2 days ago

I disagree. Julia has correctnes issues because it chose maximum composability over specifying interfaces explicitly. And those are not just in immature packages but also in complex packages. Compared to other languages, Julia has no facilities to help structure large complex code bases. And this also leads to bad error messages and bad documentation.
Recently we got the public keyword, but even the PR there says:
"NOTE: This PR is not a complete solution to the "public interfaces are typically not well specified in Julia" problem. We would need to implement much than this to get to that point. Work on that problem is ongoing in Base and packages and contributions are welcome."