“they don’t want learn new stuff”
I have made a similar observation in the circuit design world as well. Though I have no solution to this issue, I think I have a bit of a grasp on what causes this mentality. Being aware of the mindset might help with how you address your audience:
- People doing science/engineering are trying to solve real world, multi-facited problems. They are typically under time pressure to do this, so they have a hard time prioritizing where to put their efforts (Is it worth my time to learn this new language? Is it going to help me solve my problem faster - or is it just going to consume my time, and actually slow down how quickly I get to converge on to the solution?)
- Unlike when you are a programmer, the software is NOT the solution, it is merely the path you chose to try to understand a phenomenon.
- People have already suggested (QUITE OFTEN) that I to learn something that will supposedly make me more efficient. After much investment in my own time, most of those suggestions (feels like 75%??) just seem to have ended up being of little value. Why should I listen to you know?
- It is very difficult to predict how long it will take to learn a new tool (like a programming language)… So you can’t really make an educated guess on how much time to invest on learning a new one. Your colleagues might feel more comfortable if they got to see real-world working examples that are already solving issues they are currently working on (especially if they are easy to understand/read).
- Their current solution might not be blazing fast (either to modify or run), but they might not feel that the software is the real bottleneck to finding a solution a the moment. Sure, the software is a bit slow, but why would they waste time learning something new if what they are using does not appear to be consuming a significant portion of their overall time?
- People might not actually be aware of how much brain power they are diverting from their issue in order to run the tools. They also might not be aware that they avoid looking at certain facets of a problem simply because the software implementation would be impractical (ie take too long) with the tools they currently use.
Hilight the familiarity of Julia
One thing you might want to do is try to focus on how Julia is not that different from what they know… But better. Though you can write somewhat similar looking code with Julia than you can with Fortran, my guess is that people want to use their Fortran code because it does complex algorithm that involved many man-hours to create. As others have suggested, it is probably better to show how you can easily call/use Fortran code from Julia, and focus on the similarity between Julia <–> Matlab for high-level code (what most scientists are probably dealing with):
- Being in the field of science, most of your colleagues probably have experience with Matlab. You might want to show a typical Matlab solution for your field (maybe one that doesn’t involve specialized toolkits), and compare (side-by-side?) how it looks in Julia.
- Hilight a few really cool things (even if they might seem mundane), like how you can create a fuction on the fly as simply as writing
f(x)=3x. What’s more familiar/natural to scientists than defining a function the same way you would write any old mathematical function???
- Oh yeah, did I mention you don’t even have to think about vectorizing every aspect of your solution… and there is a good chance that it will be fast anyhow??
You can talk about how your solutions end up being easier to maintain than with Matlab:
- One of the things I dislike about Matlab is the idea of needing one file for each function you create. Though not conceptually a real issue, it seems that this simple overhead for writing a function sort of influences people to write large, monolithic functions that cannot be re-used easily… Nor can they easily be read/understood!!
- Functions in Matlab used to be pass-by-value, which made decomposing a solution in multiple functions a slow proposition (in terms of run time). That has changed (somewhat recently) by allowing function arguments to be passed by reference, but from what I have seen, the syntax is somewhat unpleasant to look at, which kind of makes you shy away from using pass-by-reference - unless you really have to.
…Just remember to make sure you don’t over-sell it. That might your colleagues reject Julia after the first hicup:
- There is a good chance you might not have all of the features of the Matlab toolkits with which you are accustomed. And if you do, you might have to do a bit of learning in order to figure out the quirks of using the Julia package (different API, etc).
- I too like the idea of IJupyter notebooks. I wish I could recommend them. Sadly, I found that my kernel often dies, and the editor (browser) is slow for some reason that I simply cannot justify. I would possibly tell my colleagues about how interesting Jupyter is conceptually (especially how you can “inline” documentation with the code, using Markdown formatting)… But that the slowness might be aggravating to some.
In my experience, the simulation is not actually the most important part of your solution. If you have no good way to see the data, then your simulation is basically useless:
- Show how easy it is to do interactive plotting using Plots.jl. Can write
plot(x,y) like in Matlab.
- Show examples they can relate to (plots your colleagues are regularly looking at).
- Suggest they choose/use a particular plotting “backend” directly when they write their final functions that plot results. The time to first plot of Plots.jl is relatively long still, and some people might find the wait to be annoying.
In case your colleagues use plots that are similar to those analog circuit designers use, you can look at the examples provided with my own plotting backend, InspectDR.jl:
They might also like the little applets I wrote that allow you to do simple interactive/exploratory work with plots:
I have a concrete example I used to wrap simple (yet very important) pre-existing C code that reads in SPICE simulator data:
This example is very nice, because it is quite simple. My guess is that you will not feel overwhelmed by the amout of Julia wrapper code.
Note that it was later ported to a pure-Julia implementation… because it is just simpler to maintain since you don’t need to compile the C library separately: