+1 for factorize(MyType, ...), Sparse(MyDist, ...) and other similar examples that have been suggested. It's only a very slight hardship for those copying their code directly from matlab, but for everyone else I think it's a big win for readability and type safety. It's also likely easier to learn (assuming you don't already know matlab too well), since it'll be easier to guess the appropriate function name without reading through a long list of jumbled letters in function names. Each method name will be more powerful, so I can see people having to reference docs less often.
On Monday, April 27, 2015 at 8:49:43 PM UTC-4, Glen H wrote: > > +1 for using multi-dispatch to separate concepts and to make things more > readable: > > cholfact -> factorize(Cholesky, ....) > sprandn -> Sparse(Normal, m, n) > > The main benefit isn't readability but for speed and generality. If you > want to use a different distribution (in sprandn) or a different > factorization type then than is easily parameterized and can be specialized > by the compiler to make the fastest code. This desire to stick with > "defacto standards" doesn't make sense because it is coming from a > different language that doesn't have multidispatch and has poor types. > > As an example, what would you call the function that factorizes > polynomials? The answer for MATLAB is "factor". I would much rather it be: > > factorize(Polynomial, ....) > > This is self documenting and all factorization methods have the same name > and and can be easily found. It would be nice to also have: > > ?factorize(Polynomial, ....) > > To return the help for how to factorize a polynomial and some way to find > out all the types that can go in the first argument of factorize(). > > If people are really set on not learning something new then there could be > a MATLAB compatibility package that does: > > cholfact -> factorize(Cholesky ...) > > But that leads to bad code so I would rather it just be a chapter in the > documentation for MATLAB users (or maybe a script to do the conversion). > > Forwards compatibility from MATLAB doesn't exist anyways so why stick to > it when it leads to worse code? > > I agree with François's reasons for why people use MATLAB...it isn't > because they came up with the best function names for all languages to > use...it likely just happened and people got used to it. > > Glen >
