Yeah, that’s a good point about backwards vs. forwards differentiation; of course there’s ReverseDiff.jl too.
I’d add that if the lead developers hope that Julia ends up with an R style ecosystem, that’s bad. I know R is successful (and popular) for what it does, but its package ecosystem is a total cacophony of interfaces and data structures (i.e. arrays vs. matrices vs. data frames) that even simple tasks that involve mixing packages developed by two different groups becomes a project in itself.
Regarding your two bulleted points, I would remark that I’d take a modest performance hit (say 10%) if it meant my development time was cut because there was less ambiguity about which package to use for what, better interoperability, and logically consistent interfaces/data structures. The interface packages and abstractions are great, if they work.
This reminds me a bit of the Trillinos vs. PETSc competition for high performance numerical linear algebra. Trillinos was probably a bit faster, at least at some tasks, but it was a software project that was a collection of independently and often times inconsistently developed packages that required auxiliary packages for clean interoperability. In contrast, PETSc had a much more unified development plan, so things tended to just work, in a consistent way, without too much effort on the user end.
1 Like