[sphw]

At the risk of exemplifying the coder turned physicist turned coder again, I think we are really talking about two slightly different fields here. There is the world of computational physics, which we haven't specifically built this tool for. Then there is the world of controls and robotics. In that world, it's very common to use highly abstracted tools like Simulink, that try and hide away all the implementation details. We are trying to bridge the gap between these two styles, by offering a more lightweight series of abstractions that still allow composability. I actually agree that for many things the more explicit, less abstract, array-first approach is good. But we also think that composability and shareability will allow teams to work faster. I think it's a hard balance to get right, but that's our goal.

[jcgrillo]

Exactly, the difference boils down to:

(a) is the calculation itself the end goal--e.g. am I trying to draw a plot which shows the motions of the three bodies?

or

(b) am I trying to use the code which describes the motion of the 3 bodies as a modular part of a system to answer other questions, perhaps interactively.

If everything is a one-off, and you're working on a very small team, of course excessive abstractions make little sense. But that's not how engineering is done. Abstractions are really important, because they allow us to collaborate.