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 AbstractMatrix).
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.)
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 kron(X,I) where X is a square matrix. However, I suspect it qualifies as an anti pattern.
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.
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 Batteries.jl or 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!
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.