Full Width 
Shortcuts 
Sign Up 
Log In 
Articles 
Reading List More from Paolo Amoroso's Journal
<![CDATA[My journey to using and programming computers started around 1983 with a Sinclair ZX Spectrum 48K, the very first I owned. At the time I was clueless. For example, I wondered whether, once I loaded a program from tape, I needed to write it back at the end of the session so that it didn't vanish when turning off the machine. The Sinclair ZX Spectrum Introduction and the Sinclair ZX Spectrum BASIC programming guides that came with the device were my first learning resources, complemented by the great Italian computer magazine MC-microcomputer. Aside from some books, in that pre-online era technical documentation wasn't easy to come by in Italy, especially foreign works in English. I pored over the Spectrum manuals, reread them many times, and experimented with the sample code. I've never been into gaming but did run many games to see what the machine could do. I've come a long way since then, hopefully. #retrocomputing #personal a href="https://remark.as/p/journal.paoloamoroso.com/the-origins-of-my-computing-journey"Discuss.../a Email | Reply @[email protected] !--emailsub--]]>
<![CDATA[GravityLoops, my gravity simulator in Interlisp and LOOPS, can finally show something on the screen. The program now animates a body of mass like the Moon interacting under gravity with a body of mass like the Earth. The dots in the simulation window here are the bodies after 180 days of simulated time, with the Earth at left. Watch the full run. Screenshot of a still frame of a simulation of a body like the Earth and one like the Moon interacting under the muatal gravity. Well, that's not much. But the code confirms the simulation loop with an offscreen buffer works well. After putting in place some infrastructure, to get there I wrote the simulation loop, tweaked a few methods, wrote a demo function that sets up the simulation, and fixed a few bugs. There's a lot more to do. I need to make the graphics of the body markers more complete and explanatory, control the speed of the animation, fix more bugs, and refactor to decouple some interclass dependencies. And, of course, GravityLoops will also have a user interface to control the simulation and enter the parameters. #GravityLoops #Interlisp #Lisp a href="https://remark.as/p/journal.paoloamoroso.com/early-simulations-with-gravityloops"Discuss.../a Email | Reply @[email protected] !--emailsub--]]>
<![CDATA[I started working on the class Universe of GravityLoops, my gravity simulator in Interlisp and LOOPS. I defined the class itself and the main methods, Universe.Register and Universe.Simulate. The class represents a collection of bodies and manages the parameters and state of the simulation. Universe.Register adds a body to a universe, Universe.Simulate runs the simulation. In the C++ code of the article my design draws inspiration from, an instance variable of the class UNIVERSE holds a pool of bodies in an array, with the most recently added body indexed by another instance variable. In GravityLoops the corresponding instance variable bodyPool is a list which, as the article notes, is more versatile and doesn't need the index. Universe.Simulate, just a stub for now, is the core method. It will update the state of the simulation, display the bodies in a graphical window along with status information, and check whether the user interrupts the simulation. The C++ program runs the simulation until the user presses a specific key and GravityLoops will have a similar feature. I'll also have the program accept a number of time ticks to step the simulation through. For Universe.Simulate I'll mostly follow the C++ code. But I plan to revisit the decision after I have something running to experiment with. I may want to split the simulation functionality into more than one method to separate the simulation itself from output, or redesign control around LOOPS' active values. #GravityLoops #Interlisp #Lisp a href="https://remark.as/p/journal.paoloamoroso.com/representing-the-universe-of-gravityloops"Discuss.../a Email | Reply @[email protected] !--emailsub--]]>
<![CDATA[I started working on GravityLoops, a software that simulates a collection of bodies interacting under the mutual gravity. I develop it on Medley in Interlisp and its object extension LOOPS, the Lisp Object-Oriented Programming System. GravityLoops will show an animation of the bodies and their motions, along with facilities for defining the parameters of the system and controlling the simulation. Motivation I've been meaning to do a LOOPS learning project but none of the ideas I initially came up with clicked. I wanted something more complex than a toy but easy enough to implement with reasonable effort. The project should also incorporate naturally the features of LOOPS, such as the gauges library of graphical meters and dials for displaying quantities. I finally stumbled upon the gravity simulator described in the article Force-Based Simulations by Todd King in the September, 1989 issue of Dr. Dobbs Journal. It's just perfect. I'm adapting to LOOPS the design of the sample C++ code that comes with the article. It's nice as it reads like an object-oriented domain specific language for simulation. The code is so short and clean I can fully understand it despite my minimal C++. I never thought I would say that of C++. There is much to like of King's program starting from its domain, astronomy and physics, which overlaps with some of my passions. The project is period accurate too as when Dr. Dobb's Journal published the article LOOPS was still under development. And, along with window systems, simulation was among the killer applications object-oriented programming proponents pointed to. The program comprises only two, hierarchically unrelated classes, a shallow inheritance design more in line with the later evolution of object-oriented programming. But the application does offer other potential classes that are a good fit for LOOPS. For example, I plan to specialize the LOOPS class Window to represent the simulaton window. I will likely need more classes for the GUI, such as dialogs for entering the simulation parameters. LOOPS is one of the subsystems best integrated with the Interlisp environment and comes with good documentation. I want to experience this high integration, the ability of combining tools designed to work together that comes natural once you're familiar with the environment. Adapting King's program to the Interlisp environment is also an opportunity to employ useful programming techniques like screen buffering to improve animation fluidity. Plus, anything that draws pretty graphics is fun. Design To adapt Todd's design to LOOPS I create matching classes with similar instance variables and methods, named according to the LOOPS style. I will rename a few confusing methods, such as UNIVERSE::service() to register a body with a universe which I'll call Universe.Register, and UNIVERSE::big_bang() to run the simulation which will become Universe.Simulate. The C++ code represents a 2D vector as a struct that I map to an Interlisp record. A class seems overkill. Todd's program outputs to the MS-DOS text console via the conio library. GravityLoops instead will draw graphics in a window. So far the code implements the Body class that represents a body. I'm about to start working on the Universe class that holds a collection of bodies and manages the parameters and state of the simulation. Once the core classes are in place I will turn to implementing the animated simulation. #GravityLoops #Interlisp #Lisp a href="https://remark.as/p/journal.paoloamoroso.com/gravityloops-a-gravity-simulator-in-interlisp-and-loops"Discuss.../a Email | Reply @[email protected] !--emailsub--]]>
<![CDATA[Insphex adds the Hexdump item to the File Browser menu to view the hex dump of the selected files. The initial implementation called the public API for adding commands at the top level of the menu. To later move the item to the See sumbenu that groups various file viewing commands I resorted to list surgery, as the API doesn't support submenus. The problem is internal system details can and do change, which happened to the File Browser menu and led to an Insphex load error. I fixed the issue by reverting the public API call and now the item is back at the top level of the menu. Insphex is a hex dump tool similar to the Linux command hexdump. I wrote it in Common Lisp on Medley Interlisp. #insphex #CommonLisp #Interlisp #Lisp a href="https://remark.as/p/journal.paoloamoroso.com/rearranging-the-file-browser-menu-for-insphex"Discuss.../a Email | Reply @[email protected] !--emailsub--]]>
More in programming
Being focused is about doing less things, and giving more space to the stuff that matters. I am spread out on too many projects and I can’t give enough attention to all of them. It’s time to clearly sort out which one I will keep maintaining and which I should drop entirely. Chuttersnap Mikochi Mikochi is a self-hostable remote file manager I’ve started in 2023. It’s my most successful open source project. I personally use it every day, and thousands of people have adopted it and started using it on their own servers. This year the project has been receiving more and more attention. Maybe it just reached a critical mass of users. In practice, that means a bit more maintenance work, since people have been pointing out bugs and suggesting new features. At the same time, working on Mikochi is fairly enjoyable. It’s a small, self-contained project made with technologies I enjoy working with. I’ve got no complaints about spending some time working on it. Verdict: Keep maintaining Mikochi and actively continue improving it. Itako Itako is an investment portfolio tracking SaaS. I built it for the most part between 2023 and 2025. In terms of scope, it’s the largest project I’ve done entirely by myself. Is it a success? Not really. There are definitely a lot of people who tried Itako, and some who’ve kept using it a bit. But it’s not engaging enough for anyone to consider getting the premium plan. And honestly I don’t find myself using it that much. My view of investing and portfolio management has significantly shifted since I started this project. While I used to think that more sophisticated analysis would lead to better returns, I now realize that the only strategies that consistently make money are honestly stupidly simple. Or maybe it’s a U curve: on one end you’ve got a monkey throwing darts, on the other end you’ve got Jane Street, and everyone in-between fails to beat the market. Anyway, the biggest issue with Itako is how dull working on it is. The interesting parts of the projects are working on statistics and data visualization. But in practice, 90% of the time is spent tediously fixing data, understanding why some German stocks have an exchange labelled XETRA instead of XETR, why some Belgian stocks still have quotes while Euronext shows them as delisted… Verdict: Shut down Itako today. Milou Milou is static site generator for press kits. It started as a fork of presskit.html which was completely abandoned at the time. It’s a very useful tool. At Tsukumogami, it’s part of our Cloudflare pipeline which builds our website in a few minutes whenever we need to change something. It seems like a few other game studios have picked it up, although I rarely get any feedback about it. I’ve not spent too much time working on it in 2026. I think it could be interesting to come back to it and add a feature or two. Better support for multiple languages could be an idea. At least, I need to make sure we don’t fall into the good old Node.js dependency rot. Verdict: Spend some time on Milou. Luluka Earlier this year, I created Luluka. It’s a CLI that allows previewing the output of Ebitengine shaders. I do still think Ebitengine is a great engine and Go is better suited for game development than most people realize. However, after quite a long period of experimentation around it, we’ve decided to remain a Godot studio. On top of having quite a large sunk cost in infrastructure surrounding Godot, the tooling and possibility of doing 3D games still makes it a more attractive engine for our use cases. And I’ve been doing a lot of 3D work lately, so better put those hours to use. Verdict: Archive the project. The rest I’ve had a lot of good ideas that stayed as almost empty repositories in my GitHub. For example, Hakumei was a terminal companion to Mikochi. I made a few commits on this project and never found the time to work on it again. I have to admit I’m probably never going to have the time to work on all those repositories. Time to archive them all!
The resiliency startup has slashed the amount it spends on AI; down from $4,500 per dev, per month, in August, to $1,600 now.
Internalize this graph, we post it on this blog a lot. If trends continue, China will have 10x the electricity of the US in 10 years. Whenever you think about geopolitical strategy, always keep it in mind, because whatever your plans are must consider this. Here’s a strategy that would make sense for America long term. Sell as many AI chips into China as possible, use the money to purchase solar panel and battery factories, and build out electricity capacity as quickly as possible. Fundamentally, compute is a function of electricity. That’s the sort of long term thinking that gives America a chance. With robotic labor, immigrants like Jensen and Elon, a business friendly culture, and an incredible chunk of land, it’s not so clear who is ahead in 50 years. Regardless, I do know this strategy would lead to massive prosperity for the citizens of both countries. However, that’s not close to what we see happening. We see a lot of short term zero sum thinking in action. It’s very scary what the US “AI race” mentality leads to. When exactly does the race end? Whatever capabilities you have today will eventually be matched, unless… …you believe that you can use ASI in a decapitating first strike. I’m worried that this is what these people see as the only way out. It probably doesn’t work, can you outthink steel and drone production? I don’t see how, see my critiques here. But I’m not totally sure, I’m not a superintelligence. And if it does work, that may be the end. My likelihood of imminent WWIII went up a lot with the nationalization of NVIDIA.
This post was previously published through my newsletter on November 9, 2026. From time to time, I will republish newsletter issues on my blog here if I think people (and search engines) might benefit from it. If you want to read everything I’ve written once it is posted, I recommend signing up for the newsletter. If you’re doing anything to stay on top of what is happening in the world of software testing and test automation, like browsing or even posting on LinkedIn, which I stopped doing for the foreseeable future, or reading blog posts - my preferred way of keeping up these days, and I highly recommend Dawid Dylowicz’s excellent Software Testing Weekly aggregator mailing list if you prefer longer-form reading, too you’d be thinking that AI has consumed our entire field, and that everybody (or at least those who post or write in public) is an AI expert these days. The reality, though, is far from that. Yes, some people use a lot of AI, even when I would only call a small fraction of them ‘experts’. I definitely do not classify myself as an ‘AI expert’, by the way. A much larger group uses AI on a less frequent basis, and they’re getting some value out of it. Sometimes more, sometimes less. That’s the group I’m probably in. And then there’s a group of people who haven’t really been using a lot of AI at all so far, beyond maybe the odd prompt to ChatGPT or Claude. I don’t have the actual numbers, but I suspect that this group is a lot larger than you would think from browsing your feed or surfing the blogosphere. You just don’t see them, because they’re typically not the people who do a lot of work in public. A few weeks ago, I started working with a small group of testers to teach them how to use AI in their daily work. This work covers both test automation as well as broader software testing tasks, as some of them contribute to automation on a daily basis, but not all of them do. I’m working with them one day per week, on average, for three months, and we’re making small steps towards making AI a more prominent tool in their tool belt. So, what are we working on right now? I’m pulling ideas from my ‘Valuable Feedback, Fast with AI’ course, and so far, we’ve spent some time setting up Claude, going over some important concepts such as context windows, models, tokens, and (of course!) the probabilistic nature of LLMs, and what that means for the results they provide. We have gone through several initial conversations, using Claude to learn more about and review specific user stories, which was an excellent segue into using talking about MCPs and setting up a connection to both Jira and Confluence using the Atlassian MCP. Last week, we also started experimenting with writing straightforward skills to make it easier for Claude to repeat certain actions in a structured way. These actions ranged from reviewing stories and acceptance criteria to refactoring small chunks of code in their (Robot Framework-based) test automation suite. What I loved about this is the avalanche of ideas that popped up in their heads when they saw how easy it was to use Claude. We made a short to-do list of ideas to try out for the next couple of weeks, and I’m looking forward to seeing them getting more confident around using Claude. One thing I have noticed is that their level of comfort around using AI varies quite a bit. Some of them are naturally quite cautious, which means they’ll ask ‘can we really do this?’ and ‘should we really do this?’ frequently before even submitting a single prompt. This is a good habit, I think, but we’ll have to do some work to get them more comfortable with using LLMs, without losing too much of that caution. Others in the group are the opposite: I need to hold them back a little, because otherwise they’ll create a beautiful mess within days, simply because they see so many opportunities to use Claude in their work. That, too, isn’t inherently bad, but I do want to teach them not just how to get the most out of an LLM, but also (more so) how to use AI prudently. Over the next couple of months, we’ll dive deeper into writing better prompts, creating and structuring skills, better context management, and creating and using agents, and probably a few more things, too. I’m looking forward to seeing these people grow more comfortable around using AI in their daily work, and figuring out where AI genuinely adds value and where it doesn’t in their own context. Is there a deeper message in this newsletter? Maybe not, and I’m just happy to tell you about this project, and how it is a great example of a what I call ‘corporate mentoring’, a very efficient way of teaching a small group of engineers new skills, within their own context. But maybe it’s also to show you that, despite what you might see on the Internet, especially those places featuring a lot of self-congratulation (I’m looking at you, LinkedIn), not everybody out there is an AI expert. At least not yet. So, if you feel like you’re ‘behind’ simply because you’re not running at least 17 agents continuously, creating 5400 merge requests per day, know that you’re not alone. Quite far from it, I would say.
