Bouncing Ball (AI Updated)

Way back in February 2006, I wrote a post where I shared a really simple way to model a bouncing ball that produced somewhat realistic rotations when the ball collided with a surface. It was all based on a 1969 American Journal of Physics article that I somehow stumbled over while doing the first week exercise in Neil Gershenfeld's famous Nature of Mathematical Modeling course at MIT. Like so many posts from that time, I was desperately trying to turn some of my school work into content on my site to keep it alive even though I was blindingly busy. It's often hard for me to re-read some of those posts because they seem so silly now but I keep them up out of principle. The post in question here is nearing 2 decades of being up on the internet. This post, though, has another distinction among all the other posts on my site. It has the highest JavaScript error rate, which I can easily see with Fullstory. The reason the error rate is so high is that the original post contained a bouncing ball simulation that was written in Java and published as a Java Applet. Many of you are not even familiar with this term, “Java Applet”. There was a time when we were all convinced that the future of programming from web pages to toasters was Java and one part of that vision was the ability to stick an element on your web page that ran a Java Virtual Machine. It even included the ability to draw things using Java's graphics libraries. It did not, as some expected, pave the way to an all Java future but it did create an impressive number of security vulnerabilities that was eclipsed only by the king of insecurity, Adobe/Macromedia Flash. This is why browsers no longer support Java Applets and they haven't supported them since around 2015. You know what happens to most pages that still have functionality in a Java Applet? They throw an error. I still get regular but slow stream of curious people arriving on that Bouncing Ball blog post, eager to see it all in action, only to find it no longer works. And on the other side, I glance at my site stats every few months to find that page still topping the list of Error Pages.

I have, for many years, wanted to take some time to remove the Applet and replace the ball simulation with something more modern, like an HTML Canvas element, but I never have taken the time to do it. During the few times when I found enough motivation to open the old Java code to assess how long it would take, I quickly retreated because it's 20 year old Java code written by a sleep deprived graduate student with very little professional software development experience. In industry parlance, “the code sucks”. Earlier today, though, I decided to do the thing that everyone else has been doing when they want some code created, but there's little reason to invest in making the code “not suck”. I asked Cursor to port it from Java to Typescript. I don't think this qualifies as vibe coding because while I did defer a coding task to an LLM, I ultimately tried to verify that the code does what I intended. To get started, I typed the following prompt,

In 2006, I wrote a Java Applet that simulated a bouncing ball using a simple model that simulated angular velocity changes on collisions. The code for that applet is in the @/java directory. I want to recreate that simulation in an HTML canvas in the vite app. The entry point for the vite app is @index.html . Can you port the Java into Typescript?

Cursor jabbered at me in the chat window for a bit and I dutifully ignored all the text, skimmed the code, and quickly accepted each of it's suggestions. I followed up a few times to ask it to add pieces that were missing from the original, including this prompt that I saved.

In the original, the ball was rendered with 2 images. @lotto-hi.png and @lotto-lo.png. @lotto-lo.png was the image of the ball's surface and was meant to rotate. @lotto-hi.png was meant to simulate ambient light and did not rotate with the ball. Can you render the ball using these images? You should make copies of them in the @/src directory.

There were some other prompts where I asked it to keep fixing various little issues or add missing elements. But after a few minutes, I did have the bouncing ball simulation running as a vite app using a canvas element. The code still sucked since the LLM mostly just ported over the Java code, but it worked and I had spent very little time on the porting effort. What you see below is the result. Well, that's mostly the result. I did fix several things, by hand, because I don't want this page to become my new leading error page. I can now update the original post to point here and be done with a decade of Java Applet errors.

The Bouncing Ball

Equations

I have to believe that many of the people who land on the old page are getting there because they are attempting to create their own bouncing ball simulation. In 2006, it was pretty hard to put math equations in web pages and so I embedded them in the page as images. Here are those same equations in a more readable form,

$$\\begin{align} v*{x2} &= \\frac{(1 - \\alpha e_x) v*{x1} + (\\alpha - e*x) R \\omega_1}{(1 + \\alpha)}, \\\\ v*{y2} &= - e*y v*{y1}, \\\\ \\omega*2 &= \\frac{(1 - \\alpha e_x) \\omega_1 + (\\alpha - e_x) R v*{y1}}{(1 + \\alpha) R} \\end{align}$$

• $\alpha$ represents rotational inertia (2/5 is a typical value).
• $v_1$ is the velocity of the ball before the collision.
• $\omega_1$ is the angular velocity of the ball before the collision.
• $R$ is the radius of the ball.
• $e_x$ and $e_y$ are the coefficients of restitution.
• $v_2$ and $\omega_2$ are the velocity and angular velocity of the ball after the collision.

Closing Thoughts

Did using AI save me a lot of time? Not really. The task of porting the code would not have taken that long and the code that the LLM produced was pretty hard to integrate and change. I can't really blame the model, I gave it garbage code as input. However, I really had no interest in recreating this project by hand. I viewed it as tedious and using Cursor made it fun, which I really do appreciate. With AI coding, I think we probably spend too much time arguing about 100x productivity promises and not enough about enjoying the experience. Using AI coding tools is a lot of fun. If you're interested in seeing what Cursor produced, you can find that in Github.