How to solve the two language problem | Hacker News Reader

How to solve the two language problem

scientificcoder.com

3 pointsyeesian3 comments

TL/DR: you have "scientists" who want to use Python (for fast development) and "developers" who want to use C++ (for speed)? Just make them all learn Julia.

This seems all from "scientist" field of view: there are tons of discussion of how Julia is better than Cython/Numba, but very few words about C++ and other developer-y parts.

I guess there are 3 possible approaches:

1. Make a scripting language like Python faster

2. Make a systems language like C++ easier for scientists, e.g. by embedding a Matlab like DSL

3. Make a completely new language targeting the ease of scripting languages and the speed of systems languages, e.g. Julia

The main advantage of 1. is ability to reuse existing Python code bases, which are huge.

Advantage of 3. is not being constrained by past Python design choices that make optimization hard.

Does 2. have any advantage over 3.? In either case you'd need to learn a new language and port old code. I guess you could argue better interop with existing productionized C++, but not sure that's a huge win?

First of all, I think "embedding Matlab like DSL in C++" is never a good idea. You will be re-inventing Python or Julia, but with less features and more bugs. If you want to go C++, the best thing than engineers can do is to pre-create nice C++ dev environment, set up all the relevant libraries (Eigen/BLAS/Sophus) and give nice, clear examples of modern readable C++ and recommended language features. And then support the scientists with C++ questions. And I cannot overstate how important "recommended language features" is: modern C++ can be almost as concise as Python... but there is also a huge number of older C++ examples which do not use it and do things the hard way. (And yes, this is a great reason to avoid C++ in new projects)

The decision also depends on your application. For example if you have your usual ETL pipeline or a batch job, held together with bash and duct tape, then use Julia (or Cython, or Numba) by all means. Especially if script exits after each job, and script inputs/outputs are using common mechanisms, like files or SQL databases.

But I have also worked on C++ codebases which were distributed and latency-sensitive. In those cases, the numeric code might be a small part, and most of the code is input/output, logging and error handling, ensuring distributed consistency, and so on. I would never dream of embedding any other language there, not Python nor Cython nor Julia.

Reply on news.ycombinator.com