A few year ago (before I was hired), my boss posted an internship looking for statistics graduate students using Julia.
Apparently no one (good?) applied, while they get on the order of a hundred applicants for their R and SAS postings.
The more coworkers who use Julia, the more valuable my work becomes internally.
Teachers, particularly at the graduate level, have an inordinate influence on what languages people are learning. Personally, I would like @compleat to be won over.
I am surprised by the combination of the amount of time you’ve apparently spent learning Julia, yet how much slower it is for you to write code in Julia.
Julia strikes me as simple, because it follows just a few rules that it applies consistently.
For example,
I would also be very unhappy with behavior like this:
A = Array{Int}(undef, 13, 34);
B = A;
A === B
# true
fill!(A, 0)
A === B
# true
fill!(A, 0.0) # or A .= 0.0
A === B # A is now a different array, because the filled value had a different type
# false
typeof(A)
# Array{Float64,2}
which it sounded like what you want?
Why should the assigned value win over the original array type? Do you want the assigned value to “win”, or would you prefer a call to promote_type?
My impression is that you would like the Julia wrapper to be much less predictable than Julia (require much deeper decision trees to figure out what a piece of code will do), but to follow a pattern of behavior more similar to your experience with certain past languages you have used.
Other people, who have used different languages, may have different preferences for their wrapper.
I’ve heard MATLAB does something like this (I don’t know MATLAB, so this may be inaccurate):
A = zeros(4, 5);
A[4, 6] = 2
size(A)
# (4, 6)
Isn’t this also really confusing?
It would make finding off-by-1 errors very difficult.
IMO, when something is ambiguous, it’s much nicer for it to throw an error and ask you to be clear than pick something, and wish you luck in tracking down the bug if it picked differently from how you expected.
And if it “only works when it’s not ambiguous”, then someone who didn’t realize what they just wrote is ambiguous will again suddenly be confused when their code does not work.
Versus telling people “add dots to make an operation elementwise”, which is a simple rule that should avoid any mystery in the future. And (in my opinion) is far better at “doing what I mean” than the behavior you get in R.
Similarly, writing to an Array will not change the Array, just its contents.