The similarity to the Matlab syntax was big selling point when Julia first appeared and honestly it was what attracted me more. Having symilarities does not mean that Julia cannot follow its own way, but I sincerely cannot feel happy when functions like linspace or others in the list provided above, are deprecated. I know that laziness in memorizing new function names is part of the reason but laziness is part of programing too.
To be clear, I don’t have an issue with the changes themselves (except for
linspace(0, pi) is so much nicer for interactive use than
range(0, stop=pi, length=50).
That said, it isn’t anybody’s first priority to communicate these changes clearly, and as a result, that communication often doesn’t happen, or when it does, it can be scattered. Writing documentation isn’t stimulating work, the lead devs have better things to do, and less-experienced users lack the ecosystem knowledge to write anything besides very granular descriptions of what a function does. When the stars align and a power user writes a blog post, hallelujah! But the language’s velocity over the past few years has been hard to keep up with, and much of the extant material will be out of date when 1.0 is released. It’ll probably be v1.2 before all the fires across the ecosystem are put out and full attention can be diverted to documentation/quality of life.
This isn’t MathWorks, Inc., and Julia’s blessedly free of cruft because of that. But with all the moving fast and breaking things, there’s a bit of a mess, and volunteer janitors are hard to find.
I really am struggling to understand what’s so difficult with
using MatlabCompat linspace(0,1,100) eye(5)
Just add MatlabCompat to your startup file and you won’t even notice the change.
Sure, this means you need a startup file. But Julia v0.7 is almost unusable without one for LinearAlegbra, Random, etc. So what’s one more package?
Whether or not I find this slightly inconvenient (I do of course), I agree with the principle that
Base should be as minimal as possible, as it’s good coding practice.
I do think
eye is not necessary, however a type for Identity matrix should be defined like
IMatrix. Because current
LinearAlgebra.UniformScaling type do not have shape information and it is not a matrix (not subtype of
We recently extended
stdlib a little bit in https://github.com/QuantumBFS/Yao.jl/blob/master/src/LuxurySparse/IMatrix.jl
This not only boost our performance, but also provide more explicit way to use an identity matrix (since you have to treat it differently according to the matrix size sometimes)
We are willing to contribute this to upstream if possible.
I think this is extremely unfair to the contributors, and I doubt you follow the PRs and issues very closely when you make these claims and statements. We actually have very active contributors who mostly do documentation (and tests!). Ofc, there is always more to do, but there are actually people who enjoy doing these parts of the development of Julia, and I think comparing their work to that of janitors is not really fair, and implying that it isn’t stimulating shows you’re underestimating the level of detailed knowledge you need to write good tests and docs.
I am sure you didn’t mean to insult anyone, and I am sure my comment is overly defensive. However, since you’re right that we don’t have an unlimited supply of labor, I don’t think there’s any reason to devalue the work that IS being done.
It seems you attributed that quote to the wrong person. I do quite a bit of coding in Matlab, and as a result there have been quite a few occasions where I’ve been annoyed with the quirks of that language. Every time Julia has moved away from Matlab syntax, I’ve found it made the language better. (I wish that they’d gotten rid of the hard-coded
f' = adjoint(f) as well.)
Yikes! What would you suggest instead?
Why should we fully adopt MATLAB idioms? Isn’t it because we think it is not perfect and then we have the Julia language?
eye is not explicit, you won’t notice which type you are using. I will vote for
IMatrix if we need something for identity matrix rather than
eye. If we have
You cannot tell whether this is a
CuArray etc. explicit is better than implicit.
MATLAB is not Julia, Python is not Julia, although Julia make use part of their idioms. I don’t think it is good to use
UniformScaling either though. But this should be another story.
f' = adjoint(f) is annoying? Is there any example for this?
33 posts were split to a new topic: On adjoints and custom postfix and infix operators
I don’t think there is anything wrong with being a janitor, and I have in fact often heard that title used in a respectful way about people who do a lot of important, low-profile work.
While I agree with much of your post, I didn’t see any devaluation of “janitorial tasks” in @stillyslalom’s post.
In finance and econometrics, there’s often a fair number of I_n (
eye(n)) floating around in the papers/texts. Since I like my programs to stick closely to the “theory,” this carries over to my attempts to code.
In the run up to 0.7, I spent some time purging
eye from all my code for my lecture notes (and using
I instead). In line with Stefan’s forecast, I had 95% luck. I believe that the only remaining case that I still have is a couple of
X is a square matrix. However, I suspect it qualifies as an anti pattern.
This is temporarily worse than it will be in the future. With the deprecation removed in
1.0-dev, we can now have a pull-request to allow
range(0, pi, length=50).
Moderator’s note: I’ve split this thread as best I could.
Ok so maybe rather than just my specific suggestions of contributing to the Wikibook and working on a
MatlabToJulia.jl (or modernizing
MatlabCompat.jl) is anyone interested in forming some sort of MATLAB/Julia users SIG which can do these sorts of things (including others’ probably better ideas than mine) in a coordinated way? This could just be a sub-forum here on Discourse (and, if people insist, a Slack channel, but ugh, Slack ).
I think individually we probably are very busy and have little time but collectively we can do a lot to turn some of the kinds of discussion we have on threads like these into some concrete solutions that build on the (1.0) core language.
Count on me! 99,99% of the engineers at INPE (National Institute for Space Research) use MATLAB and an easy update path is required
MatlabCompat is fine. But we need to make it come back to life.
I’m sorry, my tone was a bit sharp. Most of the small handful of contributions I’ve made to the language and ecosystem have been docs-related, I’ve worked as an actual janitor, and I really do appreciate well-written documentation. I’m just looking forward to the ecosystem documentation/blogs/examples catching up to the language (and ready to help once 1.0 and major peripheral packages are stable).
Re: Matlab, I don’t think we need to copy the syntax, per se, but I’d like a
KitchenSink.jl package that just reexports other packages to provide functionality on par with what’s built into Matlab. (FFTW, SpecialFunctions, Plots, LinearAlgebra, Images, DataFrames, Interpolations, Roots, Random, LsqFit, QuadGK, DifferentialEquations, ???)
Frankly I feel that Matlab developers have made a number of questionable choices over the years, and very rarely they made the effort to correct them. Consistency and obviousness is a great advantage of Julia!
@StefanKarpinski could we get perhaps a subcategory of Development?
I’m not Stefan, but I’m also a moderator here — why don’t you start with a new thread and if there’s sufficient interest/traffic we can expand it out to a subcategory. Really, though, I think this would be best coordinated around a specific repository (like MatlabCompat) and discussion within issues there.