I would argue that default element-wise operations and 0 based indexing can lead to a lot of cognitive overhead vs the "more math-y" notation of MATLAB or Julia. And overloaded operators like block matrix notation or linear solves are much closer.
The type system in Julia is perhaps even better than MATLAB for some linear algebra operations (a Vector is always a Vector, a scalar is always a scalar). But the Python ecosystem is often far superior to both, and MATLAB has toolboxes which don't have equivalents in either other language. Julia has some uniquely strong package ecosystems (autodiff to some extent, differential equations, optimization), but far fewer.
> the Python ecosystem is often far superior to both
What would you say does the Python ecosystem have that the others are missing? The obvious thing is pytorch/tensorflow/.... I can't think of much else though.
>The obvious thing is pytorch/tensorflow/.... I can't think of much else though.
Julia has Flux, which is great. To create a neural network with Flux, you write the forward operation however you want and just auto differentiate the whole thing automatically and get a trainable net.
It is extremely flexible and intuitive.
What Julia lacks is everything which isn't numerical analysis though.
I agree that Flux.jl is very cool but you can't use it to train a SOTA LLM, can you? The Julia ecosystem does not have the resources to even attempt building a viable alternative to Pytorch.
I'm still curious what concrete things you mean that Julia is missing. Maybe I'm so stuck doing numerical analysis, can't think of anything else...
>I'm still curious what concrete things you mean that Julia is missing.
Basically everything not related to numerical analysis. The problem isn't that there isn't an option which does work, but that those options aren't fully developed and mature to actually use for a commercial project.
E.g. look at GUI libraries, the native ones are just wrappers around other libraries and poorly documented. There is a single web framework, but is that supported enough that you would bet your entire company on it being continually supported?
If you are doing anything which isn't related to numerical analysis, Julia isn't your first choice, it also isn't your second or third choice. And I think that is fine, clearly Julia wants to be a good at a particular thing and has achieved that.
> and just auto differentiate the whole thing automatically
Not so simple as it sounds. A lot of speed advantages of Julia comes from doing in place ops on arrays and Zygote does not work with in place updates. So you end up copying and then at that point Python + PyTorch becomes a superior choice as Python is the de facto the universal language.
Pytorch and tensorflow is pretty big. It implies all state of the art research code is not written in Julia, so it is a non-starter for any neural network based project.
That is just total nonsense. You can of course do neural network research without pytorch and tensorflow. Julia is especially good, with Flux being the most flexible Neural Network library which exists.
Pytorch and tensorflow are important and a very good reason to use python or C++, but those two being unavailable is more impactful for the industry, of course your research might need them, but it might very well not.
I disagree on the zero-based indexing complaint. Indeed, the fact that Julia indexed from 1 is the sole reason I will never use an otherwise great language. I can’t comprehend how people came to the conclusion this was a good idea.
Julia being a mostly functional non-systems-programming language, where memory addressing is usually in the background, I think you'd find you rarely use numeric-literal indexing and you were getting upset over nothing.
The typical looping over i from 1 to length(a) is not idiomatic in Julia, where looping over eachindex() or pairs() abstracts away any concern over index type (OffsetArray can have an arbitrary first index). There's firstindex() and lastindex(); bracket indexing syntax has begin and end special keywords. Multidimensional arrays have axes().
"But what about modular arithmetic to calculate 1-based indexes?"
Julia has mod1(), fld1(), etc., which also provide a hint to anyone reading the code that it might be computing things to be used as index-like objects (rather than pure arithmetic or offset computation).
The strict way to handle indexing, I suppose, would be to have distinct 1-indexed (e.g. Ind1) and 0-indexed (e.g. Ind0) Int-based types, and refuse to accept regular Ints as indexes. That would eliminate ambiguity, at the cost of Int-to-Ind[01] conversions all over the place (if one insists on using lots of numeric literals as indexes). And how would one abstract away modular arithmetic differences between the Ind0 and Ind1 types? By redefining regular mod and div for Ind1? That would be hella confusing, so that abstraction probably isn't viable.
> The strict way to handle indexing, I suppose, would be to have distinct 1-indexed (e.g. Ind1) and 0-indexed (e.g. Ind0) Int-based types, and refuse to accept regular Ints as indexes.
I would be happy if unsigned integer UInt would start indexing from 0, whereas for signed integer it would start from 1. Also a module level parameter where preference on whether a literal integer shall be interpreted as Int or UInt would alleviate many usability issues there.
It seems that a lot of programmers have trouble distinguishing between indexing and offsets.
This is probably due to legacy of C language which conflates those two, possibly for performance and simplicity reasons. Same goes for case sensitivity in programming languages, again a legacy of C...are Print, print and PRINT really different functions, is that really what you intended???
Anyway, indexing is enumerating elements and it naturally starts at 1 for the first element and goes to Count for the last.
Offsets are pointer arithmetic artifact where first element is at offset of 0 for most but not all data structures.
Then you get "modern" languages like Python where they adopt indexing from 0 (no offsets since there are no pointers) and range where start is inclusive and end is exclusive...very natural behavior there. Oh, and lets make it case sensitive so you never know if it's Print, print, PRINT...or count, Count and COUNT until you run for 20 min and then crash.
I'm confused that you're bringing in case sensitivity into the discussion. For simplicity, early systems could not be case sensitive because they didn't have a large enough character set.
The comment about crashing due to spelling error really should be addressed by some form of static analysis, not by making name lookups more relaxed, in my opinion.
You think mathematicians had it all wrong for centuries?
Incidentally, I find it amusing that in Europe, the ground floor is zero, while in the US, it's one. (A friend of mine arrived at college in the US and was told that her room was on the first floor. She asked whether there was a lift as her suitcase was quite heavy...)
> You think mathematicians had it all wrong for centuries
As a mathematician, yes, I do. Pretty much everything becomes simpler if you treat zero as the first natural number.
> Incidentally, I find it amusing that in Europe, the ground floor is zero, while in the US, it's one.
I really think it makes no sense to number the ground floor as 1. This means if you want to know the height of the nth floor, you have to multiply the height of a story by (n-1).
There are a ton of other cases where you have to needlessly subtract 1 when people use 1-based indexing. To name a few
- Dates: why did the 21st century start on 1/1/2001? Why are the 1800s the 19th century? It doesn’t make any sense. If we indexed from zero, today would be 5/0/2023 (5 months, 0 days, 2023 years since the common era), in the 20th century. It all becomes so easy and intuitive.
- Mathematical foundations: If we are using set theory to encode mathematics, how is the number 1 defined? As a set containing itself? This leads to paradoxes in many cases. As the set containing a different single element? Then we can call its contents 0.
- Musical intervals: why do two thirds (ok, major and minor, but I’ll gloss over that) make a fifth? Does 3+3=5? The fact that musical intervals index from 1 significantly increases the cognitive burden for music theory. It becomes much easier when we index from 0.
- Birthdays: Age is correctly indexed from zero, but it may seem counterintuitive that your first birthday is the day you are born. So when is your second birthday? The day you turn 1, of course. The word “third” sounds like 3, so it seems reasonable to me to introduce a new ordinal here (I like “toward”).
- Computing: languages that use 1-based indexing are obscuring what is actually going on; they generally just subtract 1 internally from the user’s input. They have to, since indexing from 0 is fundamentally more efficient at the hardware level. 4 bits can only store 15 possible addresses if you throw away 0.
These are just a few examples and by no means an exhaustive list. Conversely, I have yet to know of a single instance where 1-based indexing makes more sense or simplifies things (aside from being more compatible with legacy features of our society).
After a while, when you think deeply about it, you start to feel that 0-based indexing is something closer to a fundamental truth, rather than simply a convention. Indeed, I propose that the only reason people find 0-based indexing counterintuitive is due to social conditioning.
>I can’t comprehend how people came to the conclusion this was a good idea.
If you look at a textbook for numerical analysis likely the algorithms will be 1-indexed. Julia is a language primarily for writing down mathematics, it would be quite silly not to use mathematical conventions.
Curious whether likely is indeed correct. Certainly the textbook my numerical analysis course had wasn't because remember playing with indices to get clean Julia code.
The type system in Julia is perhaps even better than MATLAB for some linear algebra operations (a Vector is always a Vector, a scalar is always a scalar). But the Python ecosystem is often far superior to both, and MATLAB has toolboxes which don't have equivalents in either other language. Julia has some uniquely strong package ecosystems (autodiff to some extent, differential equations, optimization), but far fewer.