Actually, A + 1 is often interpreted to mean 'add one to the diagonal of A ’
That’s what I was going to say. I’ve very often had the trouble in matlab and in previous versions of julia where I write some mathematical formula like (A - lambda) x. This results in very dangerous errors where the result breaks my expectations in ways that are not easy to spot. Julia now takes a more principled view that recognizes that arrays have the dual purpose of information containers (eg a matrix to represent an image) and of linear algebra objects (eg a matrix to represent a linear transform). That does mean that I often have to correct my code when I forget the dot in abs(A-B), but having an error is miles better than introducing tricky bugs. (that’s why I don’t like the current behavior of having exp(A) be the matrix exponential, but that ship has sailed)
About the Matrix Exponential and other functions, I was going to mention… isn’t there only an ambiguity when the matrix is square? Why not only throw an error when the ambiguity occurs? There isn’t always a need to scold the ‘naughty’. That is what I meant about broadcasting earlier, not that I didn’t like it, but that I would expect intuitively that it would be implicit unless an ambiguity were to arise. This is the kind of thing I mean. Maybe if there were a Wrapper to correct these kinds of things in the case of no ambiguity.
Maybe what I am talking about is merely a ‘smart’ IDE?
[JUNO/ATOM is hopeless, anyway,(IMO) btw - I can’t even get ATOM to run properly on Ubuntu without GTK errors despite combing the blogs]
I am not trolling, especially as I added (IMO -in my opinion). I assume people are allowed to express opinions on here. And to be clear, it is not JUNO that is the problem…
Don’t you think a properly functioning ‘smart’ IDE would be helpful? I believe that is a constructive suggestion?
It most certainly is not. Being able to separate datatypes into mutable and non-mutable is a very important technique in constructing quality software.
Many is the time, and it’s a bit embarrassing to admit, that Julia has told me i was trying to modify an immutable type when, in fact, I should not have been trying to modify a variable.
I find ‘total immutability’, a la a pure functional language like Haskell, to be a bit tedious, but immutability as a tool in the toolbox is extraordinarily useful.
With regard to your idea about having an error without parentheses, that seems intuitive and sensible (IMO), I don’t know what you mean by ‘brittle’.
It’s brittle in the sense that it would break from very slight changes, like seemingly insignificant parentheses or extracting part of the computation into a separate bit of code and saving it as a variable.
A+1 is unambiguous, at least.Why can’t that work?
One of these operations has to not work to avoid the associativity failure:
A + I — Matrix + UniformScaling
I + 1 — UniformScaling + Number
(A + I) + 1 — Matrix + Number
A + (I + 1) — Matrix + UniformScaling
You’re arguing that A + 1 should be allowed, which is the same operation as (3) here, so one of these other operations must be disallowed in order to avoid associativity failure. Which would you get rid of? Matrix + UniformScaling (1 & 4) or UniformScaling + Number (2)?
So is what you’re suggesting is that exp(A) would compute the matrix exponential when A is square but compute the elementwise exponential otherwise (i.e. non-square matrices and arrays of any dimension but two)?
That seems bad. Suppose you write a function that takes an array argument and uses exp(A) to apply exp elementwise to each element. It’s works great, all is well. Then someone (perhaps you) uses your function on an array that happens to be a square matrix. Oops. Now it does the wrong thing in that one special case.
Maybe a smart IDE or debugger, then, that would suggest the correction.
Maybe lots of this boils down to the fact that when one makes a mistake like this, there is nothing in the error messages the suggests what the problem really is.
It’s very unlikely there are many people lecturing MBAs on this forum, and it’s not clear that MBAs would benefit from using Julia.
I think your LaTeX/Plain TeX analogy is perfect explanation why this is a bad idea: LaTeX overlaps TeX in a very weird way, it’s not a subset nor a superset, and made incompatible changes that are arguably inferior (give me \pmatrix{...} over \begin{pmatrix} ... \end{pmatrix} any day). It also solved zero problems that couldn’t have been solved better as TeX macros.
But LaTeX won out because it was easier to use, and now no one (apart from me as far as I know) uses or learns Plain TeX. Just because it “won” doesn’t mean it was a good idea.
With Julia, you have to learn one rule about vectorization: if you want elementwise/broadcasting operations, use a dot. This applies to every function, from + to exp to less-algebraic functions like occursin or first.
It’s true that this is different from e.g. Matlab, and new languages take time getting used to. But it’s not a rule that is hard to explain, I think, whereas adding lots of exceptions to a rule makes things harder to learn in the long run.
That’s the main reason why we removed array + scalar. It was initially removed on algebraic grounds (https://github.com/JuliaLang/julia/pull/5810), then that change was reverted because it was too inconvenient (https://github.com/JuliaLang/julia/pull/7226) for + to be an exception to all the other vectorized operations that we had at the time, and then finally it was removed again (https://github.com/JuliaLang/julia/pull/22932) when all of the other implicit vectorization had been removed in favor of “dot calls” and + was the last holdout. (Moreover, it turns out that there are strong reasons to encourage people to use “dot calls” uniformly for vectorization, besides mere consistency, because they enable loop fusion optimization.)
Believe me, your concern about array + scalar was considered very seriously over a long period of time as you will find if you read the linked issues. Although the end result is that Julia is indeed different from Matlab or Numpy, this difference is compensated by having a rule that you have to learn only once, for all functions.
Perhaps if the error message in this case were a little more helpful in highlighting the issue, it would make a significant difference. Anyway, this is not my biggest concern, but was just an example.
I am sorry if my frustration has caused me to express myself in such a strident manner here, but the reality is that I have spent many hundreds of hours trying to make Julia work for me, translating much of my code from MATLAB, python, and R, and I continue to find that coding in Julia takes me between 10 and 50 times longer in Julia, even if it runs better when it is done. I do not know exactly why that is the case, but it is, despite my being a very experienced coder (and not, I think, being a total idiot). Perhaps my comments here have not necessarily identified the issues in the right way, but the reality is that I really would like to move to just Julia, including my teaching (even MBA’s!) but I am struggling myself, and don’t feel I can ask my students to experience the same frustrations that I do. This is not a ‘troll’, but an honest opinion, from lots of experience and hours spent, including reading documentation and blogs, as well as coding.
Most people agree that julia’s error messages are not as good as they could be and error message improvements is high on the list of the core developer’s todo list. However, the core devs have lots other work they also want to do. If you want to help contribute to improving the error messages, I’m sure your help would be greatly appreciated.
Regarding your concerns about being talked down to and feeling like people are calling you stupid, I’m sorry you feel that way and I don’t think anyone here intends to imply that you’re stupid. Rather, I think that what you are detecting is that people don’t seem to be taking your concerns or input very seriously and may be acting dismissively towards you. I can’t speak for anyone but myself here, but I think the likely explanation is that people may feel that you are making sweeping suggestions for wide-scale changes based on what appears to be your initial impressions after only using Julia a very short time.
While the impressions and feedback from new users is valuable, it’s also difficult to respond to because nearly everything that’s been brought up has been discussed to death before by people with a lot of context and deep knowledge about julia, competing languages and general design.
You mentioned that you’ve taught large classes to beginners. Perhaps a good analogy would be to imagine how you would respond if after a week of lecture, a student came to you and started airing their grievances with your chosen curriculum.
Why are we discussing topic A right now? My friend at the other university is learning topic B fist. If it’s too late and you can’t switch to B, maybe just start offering another course concurrently that does B before A please.
I have a lot of friends looking to go to university and I’m afraid I can’t recommend that they attend here until you offer a stream that does B before A.
Is this valuable feedback that you should consider and think about? Yes, but chances are you’ve thought about the curriculum you’re teaching, discussed with your colleagues and after considering many of varied points of view, decided that the curriculum you chose was the right choice. I don’t think it would be very reasonable of this hypothetical student to get angry if their suggestions weren’t immediately followed or taken seriously.
Thanks for your thoughts, but I have been working with julia for about 9 months now, and spending quite a bit of time with it. I wouldn’t be making these comments otherwise.
Fair enough, 9 months is quite a long time to use a language and still be frustrated with it. It may just not be the language for you then, if you still find yourself fighting against it like that.
My experience and that of most julia users I know was that it felt quite natural from early on, but everyone’s different.