[noobermin]

You can always tell when developers and computer scientists try to "fix" computational physics, sigh. It looks "easy" when you have a helper method/call for common things like 1/r^2 or something like that but what about when you want something more tedious than that? I don't see how the example is better than a python script/fortran code with a bunch of arrays. Like the three body example, a script with arrays would be much simpler and take less boilerplate than a lot of what they had there, and adding the third body is a simple as making N=2 instead of N=3. The usual argument that codes in the computational style are messy and hard to read really only applies if you don't know physics which while daunting need not be, like anything it just needs to be learned.

Anyway, to each their own, it's fine for people who somehow think because there are wrapper methods everywhere a code is "cleaner". I just submit that this really is a aesthetic preference, and that instead of trying to "fix" other professions, understand there are often reasons why things are that way when everyone in a field works that way.

[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.

[cl3misch]

Nicely put, thank you. What can sadly be even worse are physicists-turned-coders who think code is good if 1. everything is encapsulated as much as possible and 2. there are comments for every line.

Of course, I once was that physicist! Now I prefer working with arrays and functions that receive arrays and return arrays, even in the top-level, user-facing script.

But who knows, maybe there will be a next stage in the journey!

[montecarl]

> there are comments for every line.

I used to work at a company that wrote an atomic scale simulation package. Every dev was a physics/chemistry PhD turned coder. We didn't quite hit one comment for _every_ line of code, but we were close! At first I really hated this style; one comment every few lines. However, I eventually learned to kind of like it, even though it was a bit redundant.

I don't really have a point here, but I just wanted to echo your statement that the physicists-turned-coder style is real!

[geysersam]

Jesus living through that now. Physics PhDs and postdocs turned coders all around. They dislike anything "not made here" and can build tools for years before a prototype solution to the actual problem exists. System design decisions are made frivolously and end user feedback is actively discouraged, "have to be careful who we show this to" one said in a meeting after something got criticized by an end user representative. I'm venting a bit but it is a culture clash for sure.

[StarlaAtNight]

Jesus is back?!? And she’s a Physics PhD?!?

[igleria]

> adding the third body is a simple as making N=2 instead of N=3

As a computer scientist this sounds odd to me, but if you are the sole consumer of your own API, you do you!