On Sat, Apr 02 2016, Spiritus Pap wrote: > Hi there, > > TL;DR: A lot of people that could use julia (researchers currently using > python) won't. I give an example of how it makes my life hard, and I try to > suggest solutions.
While there are surely people who could use Julia but aren't, this applies many languages. IMO people should be chosing languages based on features which reflect deep architectural choices about a language: for Julia these could be parametric types, multimethods, a combination of the latter, macros, numerical performance, etc. The problem with trivial features such as which operator has an infix form in Base and choice of indexing is that there are so many choices, with reasonable arguments for many options, so by definition it is impossible to please everyone. > I REALLY tried to use julia, I really did. I tried to convince my friends > at work to use it too. > However, there are a few things that make it unusable the way it is. If such trivial features are dealbreakers for you, I would assume that you have not invested enough time in learning about more important features of Julia. In any case, "unusable" is a very strong word, and would surprise many people who are already using the language productively. > Decisions that in my opinion were made by people who do not write > research-code: > 1. Indexing in Julia. being 1 based and inclusive, instead of 0 based and > not including the end (like in c/python/lots of other stuff) > 2. No simple integer-division operator. > > A simple example why it makes my *life hard*: Assume there is an array of > size 100, and i want to take the i_th portion of it out of n. This is a > common scenario for research-code, at least for me and my friends. > In python: > a[i*100/n:(i+1)*100/n] > In julia: > a[1+div(i*100,n):div((i+1)*100,n)] Define portion(i,n,m=100) = 1+div(i*m,n):div((i+1)*m,n) and use a[portion(i,n)] and your code will become much cleaner. > A lot more cumbersome in julia, and it is annoying and unattractive. This > is just a simple example. If you are repeating something all the time and find it cumbersome, wrap it in a function. > *About the division:* I would suggest *adding *an integer division > *operator*, such as *//*. Would help a lot. Yes, I think it should be by > default, so that newcomers would need the least amount of effort to use > julia comfortably. // is already being used in Base for rational division. > *About the indexing:* I realize that this is a decision made a long time > ago, and everything is built this way. Yes, it is like matlab, and no, it > is not a good thing. > I am a mathematician, and I almost always index my sequences expressions in > 0, it usually just makes more sense. See https://github.com/JuliaLang/julia/issues/558 and countless discussions about this. > The problem is both in array (e.g. a[0]) and in slice (e.g. 0:10). > An array could be solved perhaps by a *custom *0 based *array object*. But > the slice? Maybe adding a 0 based *slice operator*(such as .. or _)? is it > possible to do so in a library? Yes, see eg https://github.com/alsam/OffsetArrays.jl > I'd be happy to write these myself, but I believe these need to be in the > standard library. Again, so that newcomers would need the least amount of > effort to use julia comfortably. The tendency is to go in the opposite direction: instead of stuffing everything into Base, move code into packages. Best, Tamas
