Parametric or Differential - An Important Distinction
Writing code that applies the math of physics to model the the world in terms of forces and motion presents two options. Either define an object's absolute position in the simulation by a variable that represents the time on the clock (t), which I have seen referred to as the"parametric" approach, or define the object's change in position that occurs during a defined amount of time-change (delta-t), which is called the "differential" approach. These two equations represent the choice:
From a coding perspective, the more robust approach is represented by the second equation - the differential method. In such an approach, if the acceleration of the object changes (say because the net force on the object changes) then the position change (delta-x) of the object will reflect that change in acceleration. In Snap!, the change x or change y move blocks will change the sprite position accordingly. This approach is essentially differential calculus and the code is simple. On the other hand, acceleration change in the application of the first equation (the parametric method) is more problematic. If the clock time (t) is used to define the absolute position (x), the clock time, starting position(x0) and starting velocity (v0) will all need to be reset in the animation. The code gets needlessly complicated. It is important for a physics teacher who requires students to use code to make mathematical models to be cognizant of the difference. Standard physics labs lead to the first equation and that equation appears in standard texts.
The Dilemma - Conform or Transform?
So, what is the dilemma? The dilemma is in deciding to study situations in which the net force changes, or not. Robust code isn't really necessary unless students will be dealing with situations in which the net force on the object changes. In a first year high-school physics course, that would probably mean modeling drag force and spring force. At most, first-year students might traditionally apply the equations that define these forces in a "plug-and-chug" manner, but would lack the sophistication to experimentally verify their accuracy or make predictions. The study of these forces is a cul de sac in a ninth-grade curriculum. A teacher that is incorporating coding into the curriculum needs to sacrifice some traditional content, and these two forces are not likely to make the cut. If changing net force situations are avoided, then it is possible for the teacher to lead students into the less robust coding, yet avoid the aforementioned pitfalls. The upside of this is that students see code that matches what is in their notes and texts. This is a reasonable conformist argument in favor of basing object position on clock time (t) rather than calculating an object;s change in position based on the time change (delta-t) that occurs in each from of the simulation. The downside of avoiding situations that involve a changing net force is that students will not get the chance to see that these more complicated situations are easily modeled with slight adjustments to code already developed for constant net force situations. This phase of programming in introductory physics might be the big payoff. If done well, students will be able to see how logical application of Newton's 2nd law is all that is needed to accurately represent simple interactions in the physical world. Furthermore, more advanced programming that involves user changing force with keyed input is also possible, opening up a new realm of possibilities for student applications. This seems to me to be a threshold where the power and thrill of modeling the physical world with code would be more evident to students and helpfully compound the depth of understanding that accrues. This is my transformist argument. Pure, compelling, tantalizing speculation. And, pursuit of this outcome with 14-year-old physics students is challenging. I now know from experience.