These reflections are based on a significant amount of work applying the modelling package Modellus to the Advancing Physics development, and then training teachers in using the package in this context.
The main user issue for teachers in using Modellus appears to be writing F= m * dv/dt, and suchlike, rather than starting the line with the differential, so writing dv/dt = F/m.
The issue is this. Users first expect '=' to be a mathematical equality. So dp/dt=F and F=dp/dt are exactly equivalent in their minds. But in Modellus, as in many or most modeling packages, the "=" is an assignment ( it can be parsed as 'let the value of dp/dt= F'.
This is an example where Modellus does not speak mathematics, but rather some language of its own, which is related to maths but is not maths. And it's quite a stylised language : a kind of pseudo-code.
There is already a do-while: it's in the iteration. Iterate these series of equations while the time is less than a certain value. In introducing Modellus, or similar modeling systems to the low-density user (so not the keen or already committed addicts). I believe that thinking about the internal dialogue (how the user is construing what the system is doing) is all-important. This is so for all software, of course, but especially so for modeling software, which has to be written to optimise the expression of intelligible ideas.The aim is for the computer to augment the human thinking, not handicap the human, so the interplay between the two is all-important.
There are many uses for a more general do..while construction, that assume time ticks along in the background.
A braking model, say, where the iterations stop when the kinetic energy is zero. Or parabola, when the ground is struck, or a wall is hit, etc.
So here's a simple story, including the natural need for a do-while.
I'm after how long it takes to come to a stop. I know how much energy is in my kinetic store. The power empties the kinetic store. The clock ticks on. Keep emptying the store until there's nothing left.
Currently this gets turned into:
=>
E=12
P=-7
dE/dt=P
Or:
=>
E=12
P=-7
E = last (E)+P*Dt
So it's a simple model. But currently there is no elegant ways in many modeling systems to terminate the run on some condition. I think we can do better.
Plotters in Modellus, for example, draw squiggly lines when you manipulate the model, even if not iterating. (its a pity that that this is not explicitly obvious to the user, as constraint modeling turns out to be rather important). At the moment I see no elegant way of starting a new manipulation with no history of squiggles all over the plotters.
That is constraining is implemented, but not presented clearly. It needs to be more explicit, as it is so important.
So I can write a model which explores maximum power output
V=E-I*r
I=E/r+R
P=V*I
Iterating over R to explore multiple conditions, using the same control mechanism as for iterating over time is asking for trouble: you're encouraging conflation of two very different modes of reasoning.
Modellus has an issue in separating models that evolve from those that constrain: too much mathematics & too little physics. Or, put another way, too much Leibniz and too little Newton.
There are two different kinds of programming languages:
Much of the talk of coding in schools focusses on procedural thinking, and this maps well onto evolutionary models, that represent processes, but perhaps do not do so well with those that represent situations. I think that there is space for further development by thinking about the affordances of these two.