[gopalv]

> is there a reason to learn Julia?

JuMP is why I learned whatever I did of Julia and that was mostly because it allowed me to express some things better (not necessarily faster or in parallel).

A good example would be this random problem that came out of an interview discussion.

https://gist.github.com/t3rmin4t0r/44d8e09e17495d1c24908fc0f...

I'm almost sure my python implementation is wrong, but I can't quite prove it - the Julia one is trivial to understand (a dot product + a minimization function).

[kevmo314]

Using an optimization library seems like the completely wrong approach to solving this interview question. Was that intentional?

[pietjepuk88]

Aside from the special case of "1" always being present, I would say that in general you should just use an optimizer to solve knapsack problems. Whether you should do so for an interview question is up for debate I guess; using libraries shows you can get something done quickly and efficiently, but implementing your own solver might show you understand the underlying complexity.

As far as comparing code complexity of Julia to Python is concerned, I would say that when you use JuMP in Julia, you should use Pyomo/CasADi/PuLP/... in Python. That is not to say that I don't find JuMP to be a more appealing framework overall. It has wide support for all kinds of solvers, and some Julia/JuMP authors even wrote fairly good MIQCP/MICP solvers on top of commercial/open-source MILP/SOCP solvers.

[kevmo314]

> I would say that in general you should just use an optimizer to solve knapsack problems.

Why do you say that? Perhaps if the knapsack problem is provably non-polynomial, but being able to distinguish those cases is a rather important skill.

For example, the problem you specified can more easily be solved directly: https://repl.it/repls/RotatingObeseBusinesses

With respect to the interview question context, if I had a candidate that implemented a solver, I would be inclined to say they completely overengineered the solution for a less optimal answer. There are a bunch of assumptions that are required for a solver to be optimal and unless the candidate can enumerate all of them and argue why the problem meets those constraints, the solver is not 100% guaranteed to be correct, whereas a direct solution is.

Not to mention, as you noted, edge cases, and the complete cryptic-ness of the code.