The last talk at JuliaCon Eindhoven Local, Myrthe Schepper’s talk on “ASML’s Julia Journey”, references the earlier talk about the “1.5 language problem”.
There she touched on two culture problem that had been articulated by @MatthijsCox in his Scientific Coder blog.
Some of the issues Julia faces are a manifestation of Conway’s Law. In short, we are likely to end up with two dialects of Julia as we try to integrate both the interests of researchers and software engineers.
We previously discussed some of these items in two prior threads.
What I see in Schepper’s talk is that the two-language problem is a very real one at industrial scale. As a research software engineer and a scientist, this is also a problem that is persistent in academia across multiple domains. Real money is spent porting dynamically typed code to statically typed code. The person writing the dynamically typed code is often not the same person writing the statically typed code.
A counterpoint to this is that it may not be a single person that writes their dynamic code and then rewrites it statically. The two or more people have to be able to communicate and need to have some comprehension of what the others are doing. While it is difficult and costly to refactor codes, some organizations have a strong interest in both producing research code and refactoring that code.
I have run into this situation across a number of languages recenty.
- Python / Cython
- Java / GraalVM
- Kotlin / Kotlin Native / Kotlin Multiplatform
- Scala / Scala Native
Developers have already accepted that not all Kotlin programs are going to be able to ported to Kotlin Native, but they still see utility in being able to build native binaries. For me, the outstanding question is “Can Julia offer a better experience than the above existing solutions or using two languages?”.