@Chris: thanks for the tips! @Tamas: oh I know what you mean, and don't worry, I'm definitely not planning on telling these people how they should do their research! But as a counterpoint: they also are so focused and busy dealing with their research problems that they don't really have the time to leisurely explore what Julia has to offer them (like in that cartoon with square wheels[0], although I find that one a bit condescending). Surely it wont hurt doing some prep-work for them by finding relevant examples, like Stefan suggests, and let them evaluate if it's worth their time.
@Stefan: one example of programming-related struggle within the group is that one of them works best in matlab, and he created new clustering algorithm called BackSPIN. Then another member of the group ported it to Python to make it more widely accessible[1]. But now the first guy has come up with an improvement for his algorithm, but the resulting matlab code is so complex that the second guy is struggling with porting it. Meanwhile, my sole contribution to the whole thing is making sure NumPy's in-place methods are used everywhere, and replacing a scalar matrix division with a one-over-scalar multiplication in the innermost loop, speeding it up by 40%. All of which required no understanding of the algorithm. Anyway, the professor pushed for the whole group to switch to Python to prevent exactly this this problem. So now a new member of the team has to learn Python because his main language so far is R. I was thinking that perhaps Julia as a language (plus PyCall, RCall and MATLAB.jl) would provide a more appealing compromise for them. What's appealing about it to me is that would be easier for me to contribute dumb-but-effective low-level optimisations while they work out better high-level algorithms. [0] https://hakanforss.files.wordpress.com/2014/03/are-you-too-busy-to-improve2.png [1] https://github.com/linnarsson-lab/BackSPIN
