It has been in my mind for a while ever since I was new to the language in late 2020, and I always see the “two-language problem” in many Julia blogs and articles. With my lack of experience in software development and programming, I am not sure if I should be concerned about it. But I am curious so I will ask away.
Are there any recent research articles that mention “two-language problem” with figures, graphs, stats, whatevers and how Julia solves the “two-language problem” (e.g. developer/development time, prototyping) in applications and development? just wanna read something
The two-language problem refers to the fact that many scientific codes are prototyped in a slow but flexible language (to test an idea quickly) but then have to be moved to a faster but less flexible language for practical applications. Translating from one language to another both slows things down and introduces bugs.
Julia addresses the 2-language problem by allowing for flexible prototyping which can be replaced by fast optimized code - all within Julia. This doesn’t mean that all code written in Julia is fast, but it does mean that slow code in Julia can be identified and optimized. This can now be done incrementally, which is less time-consuming and less prone to introducing bugs.
Found at the “issue” (that neither mentions the term)…
It’s only 143 pages (yes, I didn’t read it all, at the time, a lot of it though, if you don’t have the time) I recommend reading chapter “2.1.1 Case study: Vandermonde matrices” (and at least a few more (earlier) chapters e.g. the introduction), even if you do not know what those are (I wasn’t familiar with Vandermonde and it’s a proxy for the general issue and that chapter comparing to as doce in Python/C sold me on Julia at the time).
1.1 The technical computing problem
aka “the two-language problem”, as I understand it, and while maybe more relecvant to technical computing, all should agree Julia is a general purpose language, as officially stated, and the problem and solution good for organizing code for maintenance, not just techical or scientific code.
"I’m expecially indepted to Stephen Johnson, for explaining to me why Julia is doomed, and subsequently working as hard as much as anybody to make it less doomed. He is the author of code in appendix B
I think both (all) will agree, Julia is now “less doomed”, or not doomed at all, even with a bright future, and good in the present. Much brighter than (most, all?, of) the other 49:
“we have discovered at least 49 programming languages designed for technical computing since Forrtan (figure 1-1). This high number begs for a explanation.”…
Table 3.1 was intriguing, because I thought multimethods to be basically a synonym for “multiple dispatch” (which Julia uses). That seemingly can’t be true, since it’s O(n) in the table (also templates, presumably from C++, so also less), and Julia (and also e.g. term rewriting) O(nm) while e.g. typeclasses O(m) and methods, virtual methods, closures and duck typing O(1).
If you find your time split between writing Python, writing C++, and writing glue code between the two, and you’re getting tired of it, you have a two-langiage problem.
In R you get exposed to the “two-language” problem quickly if you want to look at internals in some statistical packages. Whenever you try to get to how things are actually done and you want to open the “black box”, you’ll find yourself in a world with RCpp and C++ code. I haven’t used much Python, but I know it’s the same. One of the things that convinced me to give Julia a try was opening the GLM.jl code and seeing Julia code inside and being able to follow how data was analyzed, almost step by step, so I could check all the intermediate steps of my calculation. I don’t know what the definition of the “two-language” problem is, but the practical consequences are pretty obvious for anyone that tries to read or develop code in slower languages.
