Thursday, April 23, 2026

Rotating space habs!

I was on a boring train journey the other day (yes, some trains still exist in the US) and my mind started to wander. I thought about the novel Rendezvous with Rama and rotating space habitats. I wondered about simulating gravity and some of the consequences. Here's are the results of my musings. I hope you like them.

(NASA/Rick Guidice, Public domain, via Wikimedia Commons)

Some basic physics of rotating bodies

To understand what a resident of a rotating habitat might experience, we need to understand two important ideas. Unfortunately, they're both a little complex. I'm going to try and explain them simply.

Centrifugal and centripetal forces

Imagine a rock on the end of a string and you're whirring the rock in a circle above your head. If you cut the string, the rock would go flying off on a tangent to the circle.

To keep going round, the rock must experience a force towards the center of the circle; a centripetal force (where -petal means towards the center). This force comes from the tension in the string.

The centrifugal force is the outward force the rock feels (-fugal meaning fleeting the center). It's sometimes said that the centrifugal force isn't real, but it is. If you've ever been on a fairground ride that spins you in a circle, you've experienced the centrifugal force for yourself and you know how real it is. The misunderstanding comes from the fact you need to use a non-inertial frame of reference to do the math.

For a rotating space habitat the centrifugal force is what someone on the inside rim of the habitat would feel as 'gravity'.

Size and rotation speed

Textbooks usually show a diagram like this to explain what's going on with the rock on a string.

The string travels round the circumference of the circle in a given time and we can express this as a linear or tangential velocity and an angular velocity. The angular velocity is usually written in terms of radians per second. The tangential velocity is the length of the circumference in $m$ divided by the time it takes to go round in $s$.

It's worth noting something important here; at any point along the string, the angular velocity is always the same, but the tangential velocity increases as you move away from the center of rotation.

Through math I'm not going to show here, we can calculate the angular and linear accelerations. The centrifugal force the rock on the string experiences is:

\[F = ma = m \omega^2 r\]

where:

$F$ is the centrifugal force
$r$ is the radius of the circle
$\omega$ is the angular velocity in radians/s
$m$ is the mass.
$a$ is the acceleration away from the center.

This means that:

\[a = \omega^2 r\]

Let's re-cast this equation into something more relevant to our rotating space habitat. It's more usual for people to think of rotation in terms of revolutions per minute instead of radians per second, so we'll make that change. We want the habitat to feel like earth, and on earth, the acceleration due to gravity is close to 9.81$ms^{-2}$ (I'll call this 1$g$). Using this value of $a$, we can rewrite the previous equation as:

\[9.81 ms^{-2} \approx \left(\frac{2\pi \text{RPM}}{60}\right)^2 r\]

which gives us the relationship between rotational speed and radius. I've plotted out this relationship below.

Note that the relationship isn't linear and as the radius gets bigger, the revolutions per minute get less. This has some important implications for our space hab.

A small habitat with a radius of 5$m$ would have to rotate at a speed of about 13.4$rpm$ to give a centrifugal equivalent of 9.81$ms^{-2}$. As we'll see, that causes problems with the Coriolis effect, but there's another problem. An astronaut in such a 'narrow' habitat would face a serious problem, the "gravity" at their feet would be different from the "gravity" at their head. For a 1.8$m$ tall astronaut, this would mean 9.81$ms^{-2}$ at their feet and 6.28$ms^{-2}$ at their head, which would be very disorienting to say the least.

What about a much larger habitat, say one with a radius of 10$km$? This habitat would spin at a rate of 0.299$rpm$. Here a 1.8$m$ astronaut would experience 9.81$ms^{-2}$ at their feet and 9.8082$ms^{-2}$ at their head. This is a really small difference and they wouldn't notice it.

For comfort then, a bigger habitat is better.

(As a side note for later, I'm going to point out that the tangential velocity for our 5$m$ habitat is 7$ms^{-1}$, and for our 10$km$ habitat it's 313.2$ms^{-1}$.)

The Coriolis effect

This is another tough one to explain. Let's start with a couple of examples and I'll explain how it works on a rotating habitat.

The earth rotates on its axis. If you're at the equator, you travel the full circumference of the earth in 24 hours. If you're at a pole, the circumference is zero. If you're halfway in-between, you travel the circumference of the earth at that point in 24 hours. Let's write down some number in a table.

Location	Latitude	Effective radius (m)	Tangential Velocity (m/s)
Equator	0°	6,378,000	463.8
45° latitude	45°	4,509,900	328.0
Pole	90°	0	0

Let's imagine I'm at the equator and I fire a cannonball due north to the halfway 45° point. The cannonball starts with the same tangential velocity (464$ms^{-1}$), but the tangential velocity at the halfway 45° point is less (328$ms^{-1}$). Relative to an observer at the halfway point, the cannonball has north velocity and an east velocity. This means, the cannonball will go east as well as north, even though it's fired in a true straight line. Here's a diagram of the flight of the cannonball.

The cannonball will travel north 5,004$km$ but it will also travel east 563$km$.

The Coriolis effect was first observed in artillery firing and modern day artillery calculation take it into account. Similarly, long-range snipers have to calculate its effect to hit their targets. It's not just a war thing; the Coriolis effect is present in the movement of air in the atmosphere and the currents in the ocean, it also affects the routes planes take.

The physics of the Coriolis effect are complicated. It's governed by this equation:

\[\textbf{F}_c = -2m( \mathbf{ \Omega} \times \textbf{v})\]

where:

$F_c$ is the Coriolis force vector
$m$ is the mass of the object
$\Omega$ is the angular velocity of the rotating frame
$v$ is the velocity of the object as seen by the rotating frame.

I'm not going to go too deeply into the math here, but you should know it's possible to work out the Coriolis effect if you have all the data.

Let me give another example of the effect before we get to the habitat. Imagine I'm on the equator of the earth standing over a very deep mine shaft. The mine shaft goes straight down deep into the earth. I drop a rock down the mine shaft. Surely, the rock will drop all the way to the bottom without hitting the sides? The Coriolis force says no. As the rock falls, the circumference at of the earth it "sees" gets less and less. If the mine shaft went to the center of the earth, the circumference of the earth would be zero. See the diagram below to get the idea.

Remember the tangential velocity at the equator is 464$ms^{-1}$ and at the poles (or at the center) it's 0$ms^{-1}$. This means, our falling rock would be subject to the Coriolis effect. After a fall of 3.7$km,$ it would move 5$m$ off center. So even if we drop the rock straight down, it may hit the sides of the shaft before it's fallen very far.

Life in a rotating hab

Now we know about “gravity” and the Coriolis force, let’s think about what that means for life in a rotating habitat.

Running and walking

If I run in the direction of spin my angular velocity increases, so I feel a greater centrifugal force. In other words, the faster I run, the heavier I feel. Of course, the opposite is also true if I run against the direction of spin. In a large hab (10$km$ radius) this isn’t really noticeable, but in a smaller hab, it can be.

A good runner can sprint 7$ms^{-1}$, which is the same as the tangential velocity in a 5$m$ hab. If our runner ran in the direction of rotation, they would feel a "gravitational" acceleration of 4g, which would be punishing to say the least. If they ran against the direction of rotation, they would become weightless!

In a 5$m$ radius hab, a person walking 1.4$ms^{-1}$ would experience a Coriolis acceleration of 3.9$ms^{-2}$, or 0.4$g$. That's a lot. It would feel that you were being pushed sideways as you walked. If you dropped an object, it would curve before hitting the floor (see the mineshaft example above). It would also be very disorienting because the fluids in your inner ear would be affected. Bottom line is, life would be very unpleasant, it would feel like you were in a never-ending fairground ride.

Life in a 10$km$ hab would be much more pleasant. The Coriolis force a person walking at 1.4$ms^{-1}$ would be about 0.09$ms^{-2}$ or about 0.009$g$. Under normal circumstances, you wouldn't feel it.

Plants

Once again, everything would be 'normal' in a 10$km$ hab.

Things would get weird in a 5$m$ hab. A tall plant or tree might actually reach 5$m$ which is the zero "gravity" area and I have no idea what might happen! Plants rely on gravity for internal fluid flow, but we know some plants can grow in space. In a 5$m$ hab, a tall plant would end up weirdly distorted or die. Of course, the Coriolis effect comes into play too. Plants would probably end up growing at an angle.

Weather

On earth, the atmosphere is affected by the Coriolis effect and it would be the same but worse on a hab. Air would likely flow in spiral patterns. In a 10$km$ hab, things might get strange, but in a 5$m$ hab of any size, things could get really strange; an astronaut might feel different wind speeds on different parts of their body.

It's not clear to me how chaotic the atmosphere would be. It's possible it would be strange (meaning different from earth), but entirely predictable. Would it rain, and if so, what would that look like?

Sports

Plainly, sports would be downright weird at 5$m$. So weird, I wonder if you could invent new games, like some kind of zany squash for physicists.

At 10$km$, things get saner, but there could still be some noticeable effects.

Golf could end up being very different. The trajectory of the ball will be dependent on its direction relative to the spin of the hab (Coriolis again). Of course, the higher the ball goes, the less "gravity" it sees, so a ball may travel further if it travels higher.

Other sports, like football and baseball or cricket, might see some weirdness at the elite level when balls are kicked or hit long distances.

If you're building a football pitch or any kind of athletic track, you'd have to think about how it's oriented. You would probably want the long axis to be perpendicular to the direction of rotation. Of course, the ground on the rim would curve upwards and you'd have to correct for that, or maybe you'd just leave it as a feature of hab sports.

Aerial recreations

Hang gliding and related recreations like paragliding would be deeply weird and probably immense fun. In a 10$km$ hab, the winds would be pretty weird giving some interesting thermals to ride. Of course, the higher you go, the less "gravity" would be (and the lower the atmospheric pressure, so you'd have to have breathing equipment). The view would be stupendous as you got closer to the center of rotation. It might even be possible to cross to a point diametrically opposite to where you started.

Thinking of aerial things, it worth pointing out that humans probably wouldn't be the only species on the hab. How would birds live in a place like this? How would they behave?

Rendezvous with Rama

This is a 1973 novel by Arthur C. Clarke about humanity's encounter with an alien space habitat with a radius of 10$km$ and a length of 50$km$. As we've seen, if the habitat were rotating at 0.299$rpm$, a habitat this size could be pretty comfortable for its residents at the rim. They wouldn't feel much of a gravity gradient between their heads and their feet, and the Coriolis effect wouldn't be very much. In the book, the astronauts entered from a central point at one end (starting from 0$g$) and descended to the rim via ladders.

(Gemini's rendering of Rama.)

Rendezvous with Mike

The Rama habitat was the starting point for my train musings, but I ended up imagining something a bit different which is a twist on the ideas here. I imagined a habitat with tapered ends instead of a cylinder, so it would look something like this in cross section.

Here's Gemini's rendering of the same thing.

What would it be like to walk up the taper towards the 0$g$ center point?

In my diagram, the taper is about 27°, which would be like climbing a staircase that went on for a long way. You'd probably have to take frequent breaks as you started off and fewer as you reached the center. Of course, breaks would give you an opportunity to admire the view, which would get better and better as you climbed.

As you ascended, "gravity" would decrease, but you'd feel a component of gravity pushing you back down the slope (there's nothing like it on earth).

The Coriolis effect would increase as you got closer to the center, to the extent that you you'd have to lean to compensate.

Plants and trees would start off "normal" on the rim, but get weirder as you got further up the taper and they'd disappear entirely once you got closer to the center. Bear in mind, the forces on the soil would push it towards the rim, so "erosion" could be severe, however, let's ignore that for now. The Coriolis effect and "gravity" would cause plants to lean towards the cylindrical section and in the direction of spin. As gravity decreased, tree growth would become weird and chaotic.

Atmospheric pressure would also fall off as you ascended. At about 5$km$ radius, you'd probably have to have breathing apparatus. At the center, the pressure could be close to zero. That would mean less and less plant and animal life as you climbed, regardless of other effects.

Once you got to the center, you'd be weightless, so you could play around with floating for a while. Of course, you'd have to be careful you didn't stray too far from the tapered end. A small deviation from the axis of rotation would mean you'd feel "gravity" again and fall. That wouldn't be so bad if you were at the end of the taper, but it would be very bad indeed if you were in the main body of the cylinder.

Diminished gravity might be a good thing for the old and infirm, so maybe there would be hospitals or retirement homes on the slopes.

Some history

Of course, I'm not the only person to have thought of this. There's a very long history of theorizing about space habitats, see this Wikipedia page for some of it: https://en.wikipedia.org/wiki/O%27Neill_cylinder. In fiction, it's not just Arthur C. Clarke's Rendezvous with Rama, there have been many novels set in rotating habs. These habs have even been in movies, including some recent ones.

The "objection" I've heard to these sorts of ideas is, why don't we fix the planet we have rather than spending money on building paradise for a few? I agree, but it's nice to dream a little.

What have I missed or got wrong?

I'm sure the weather in a large hab would be more complex that I've described. Maybe there would be permanent clouds along the axis of rotation? Where would lighting come from?

A central sea (as in Rama) would be weird. I wonder how it would behave? Maybe it would be an attraction for surfers - could you imagine surfing a wave for many kilometers?

I'm sure the experience of walking up the taper would be quite something and I'm sure it would be weirder than I described here.

I'd love to hear your views of this post, What have I got wrong? What did I miss?

Tuesday, April 7, 2026

Ralph for beginners

What's Ralph and why do you care?

Ralph is all about automating the code generating process. You can use it to build small applications while you eat your lunch and build bigger applications while you sleep. Apart from the initial setup, the skills required are mostly those of a product manager; specifically, the ability to write a detailed requirements document.

Why do we need another Ralph blog post?

I found it hard to get going with Ralph because the existing content was either too theoretical or not practical enough. I figured it out in the end, but I thought I could write something to help other people get going faster, so that's what you're reading.

The what and why of Ralph

LLMs have a limited context window, which means they can only do a limited amount of reasoning. In turn, this means LLMs have problems generating code for large or complex projects. In my experience, once the prompt gets beyond a page or two, the quality falls off and code gen starts to miss things. The net result is, you need to have a human in the loop to code or to prompt; the human spots places where code gen has failed and prompts the LLM to fix the issues.

Ralph solves the problem by slicing the whole project into "bite-size requirements" with acceptance criteria after each requirement. If code gen for a requirement doesn't meet its acceptance criteria, Ralph tries again. In this way. it constructs the project step-by-step until it's built all the requirements and so delivers the complete project. The entire process is automated and there's no human involvement.

(Gemini's view of the Ralph loop. A nice AI generated image about AI.)

The Ralph loop gets its name from The Simpson's character Ralph Wiggum. If you've never watched The Simpson's, here's what you need to know: Ralph is well-meaning, but intellectually slow. Imagine you're instructing Ralph on how to build something. You'd break down the project into chunks and have Ralph run tests to make sure each chunk was correct before moving onto the next chunk. Ralph would build the project piece-by-piece until the whole thing was finished. This way might be slow, but you'd get it done right.

Ralph Wiggum, Fair use, Link

AIs and CLI

To get Ralph to work, you'll need to install a code gen CLI on you local machine. The most common tutorials I've seen on the web use the Claude CLI, so install this if you don't have an existing code gen solution. I got Ralph working with Cursor via the Cursor CLI, so I know that works too. Whatever AI you choose, you'll need an active subscription; you're not going to do this for free.

Skills

Next up, you'll need to install a skills file for your LLM. If this were a normal blog post, I'd tell you exactly where to go to get the skills file, but I'm not going to do that. The Ralph world is changing so quickly, any links I give you will be out of date by the time you read this. You'll need to search to get the latest version of the Ralph skills file you need.

(Skills enable code generation tools to do specific tasks. If you don't know what a skills file is in the context of a code-generating LLM, take some time to find out before moving ahead.)

Git for the LLM to use

As I'll explain later, Ralph uses git, so you'll need a git account and you'll need to create a repo for this project. I used my GitHub account, so I know GitHub works fine for this.

The Product Requirements Document (PRD)

This is where the fun starts. You need to write a Products Requirements Document using Markdown. The PRD lists all the requirements, each requirement being a "bite-sized chunk". Here's an excerpt from a PRD.md file on my system.

MBTA-002: How the app appears to users
Description

The app will consist of three pages: "trains & alerts", "map & facilities", and "about".
It will be possible for the user to easily navigate between pages (e.g. using a tab control or buttons).

Acceptance criteria

There are three pages on the app: "trains & alerts", "map & facilities", and "about".
On each page, the user can navigate to the other pages using a control, e.g. a tab control or buttons.

Here's what's going on

The PRD consists of multiple sections like this one. Each section is a "bite-sized chunk" of functionality the LLM can generate code for. Think of the sections as individual requirements.
The section (or requirement) title includes an ID (MBTA-002) and a descriptive title.
The Description sub-section contains bullet points that describe the functionality you want. Remember, the point of the Ralph loop is to keep things simple, so keep the sub-section short.
The Acceptance criteria sub-section states the criteria the generated code must pass. If the code passes, the LLM moves onto the next requirement. If it doesn't pass, it repeats the code generation process (there's more to this I'll discuss later).

Anyone with good Product Management skills should be able to quickly build a PRD like this.

(In practice, the Acceptance criteria sub-section looks a lot like the Description sub-section. What I do is write up the Description sub-section, then ask my LLM to add acceptance criteria based on my Description. I then add in any new acceptance criteria I can think of.)

PRD.md to JSON

The Ralph loop processes a JSON file, so the next step is the production of a JSON file from the PRD.md file. This is done using the skill you installed earlier. It's a simple call to a bash script; on my Cursor installation, the script is called convert.sh.

The output is a long JSON file consisting of multiple records. Each record is a requirement taken from the PRD.md file. Here's the JSON record for the requirement in the previous section.

{
"id": "2.1",
"category": "ui",
"story": "Build base template with BosWay branding and navigation between three pages.",
"steps": [
"Header shows BosWay and page context e.g. BosWay - about (MBTA-001).",
"Add tabs or buttons to switch trains & alerts, map & facilities, about (MBTA-002)."
],
"acceptance": "Three routes work; every page can reach the other two; titles consistent with PRD.",
"priority": 3,
"passes": false,
"notes": ""
},

This JSON record is so important, I'm going to ask you to take a closer look at it. You can see the Description and the Acceptance criteria here, albeit worded differently. The other three sections to look at are priority, passes, and notes.

priority tells the Ralph loop what to work on next (start with the highest priority and working down).
passes. This starts as false. If the LLM successfully implements the requirement, it sets this value to true.
notes. This contains notes for the LLM on the next pass through the loop. Let's say the loop fails the Acceptance criteria, the notes field will contain details on the failure. On the next pass of the loop, the LLM uses these notes to try and do better. What generates these notes? The LLM.

The fields in the JSON records are read and updated by the Ralph loop. There's no human in the loop. In practice, you probably won't even view the JSON file.

Once you've generated the JSON file, you're ready to run the Ralph loop.

The Ralph loop

The Ralph loop takes the JSON file as input and processes the requirements one-by-one, starting with the most important. The bash file to do it is called start.sh on my system and it's a little complex. I'll talk through how it works at a high level, leaving out some advanced bits.

Before starting the loop, the code performs various checks, e.g. the JSON file exists, the git settings are correct and so on.

The script then moves onto the Ralph loop. Because the Ralph loop does a lot, I'm going break it down piece-by-piece.

On each trip round the loop, the code starts with some checks. It checks if the process is rate-limited on the AI API or if there are other reasons why it can't continue.
From the JSON file, it reads the requirement with the highest priority where passes is false.
It passes this requirement to the AI API along with the current git code version.
The AI generates code, or changes the existing code, to meet the requirement.
The AI generates tests based on the acceptance criteria.
- If the tests pass, the AI updates the JSON passes field to true.
- If the tests fail, the AI may update the notes field to provide a hint how to do better next time round. (Remember, the passes field is false by default so it doesn't change the value if the loop fails.)
The loop saves the generated code to a local git branch.

In the loop, there are some more advanced bits and pieces I'm going to briefly mention here that might be important to you:

There are API call timeouts.
You can set a maximum number of iterations to prevent the loop getting stuck and burning through your tokens.
There's a circuit breaker that can stop the loop if zero files are changed or if the same error is detected on multiple loops.
You can set a rate limit to prevent the LLM provider from banning you.

There main Ralph file (start.sh) calls several bash scripts to run checks etc.

When the Ralph loop finishes, you should have the code for your project. In practice, you'll need to tweak what you get back, but in my experience, you'll be very close.

How long the loop takes depends on the thoroughness of your PRD and the size of your project. As a general rule of thumb, a smallish project (e.g. building an interactive web app based on a simple data source) might take an hour.

Cost!

Ralph burns through API calls. Most LLM providers will give you a limited number of API calls per month which is separate from your token allocation. Even one Ralph project can burn through your entire API allocation. The bottom line is, Ralph can be an expensive thing to play with (low hundreds of USD to properly experiment). I suggest you think carefully about your projects and test Ralph in a considered way.

The reality

I've made it sound like the Ralph process is quite smooth. Right now, it isn't, there are bumps along the way, for example, the setup process is a little complicated, the Ralph loop reporting needs a bit of user-friendly tweaking, the online descriptions aren't as helpful as they should be, and so on.

BUT.

It works and it works well.

My experience

It took me some effort to get Ralph up and running, but once I figured it out, it blew me away. It built an entire project without human intervention and it got it nearly right. Importantly, I realized the bits it missed were gaps in the PRD. In other words, I needed a better spec.

The Ralph loop changes the balance of skills in favor of a more detailed up-front spec that anyone with product management skills can write.

That's quite a profound change.

My recommendations

I do recommend you try a Ralph loop for yourself and I have some suggestions for making your experimentation easier.

Allocate enough setup time to install skills etc. This can be frustrating, so be prepared.
Choose a project you've done before. This means you know what the end result should be.
Write a very detailed PRD as described above. Use an LLM to add acceptance criteria and add some of your own. Thoroughness here is key.
Run the Ralph loop.
Compare the Ralph results to your prior results.

Good luck!

Tuesday, March 10, 2026

Arthur C. Clarke and AI

The history of AI

I was looking over the history of AI and I was struck by how far ahead of the curve Arthur C. Clarke was. It's not just technical issues either, he was way ahead on the cultural impacts as we'll see. Of course, Clarke was too optimistic about when AI would arrive, but I think we can forgive him that.

(ITU Pictures, CC BY 2.0, via Wikimedia Commons)

Clarke and AI in his fiction

Clarke wrote quite a lot about AI and computing. The most famous example is the psychopathic AGI HAL 9000 in the 1968 movie "2001: A Space Odyssey", but he had been writing about computing for some time. In 1953, he published "The Nine Billion Names of God" which has a computer as a central element, and there followed several novels and stories through the 1950s and 1960s. In 1979's, "The Fountains of Paradise", one of the characters has a medical implant that can synthesize speech to call for help if the wearer has a medical emergency.

Clarke's AI futurism

Although he's mostly known today as a science fiction writer, Clarke also popped up on TV as a futurist, giving his thoughts on how technology might develop. This included speaking about AI and its implications. Listening to these recordings now is eye-opening as we'll see.

The first clip is from 1964. Some of his futurism is (way) off, but a surprising amount is accurate. I was going to just give you a link to the AI piece, but the whole clip is worth listening to.

Here's a Nova episode from 1978 about the new "thinking machines". Clarke's segments are worth viewing. He speaks at the start, and at 34:44, 36:27, and most importantly at 41:35. If you want a bit of a chill, go to 52:48.

If you didn't know these clips were from 1978 and had the transcript alone, when would you think they had been recorded?

Ahead of his time: society vs technology

I was at a conference in 2025 where experts were speaking on AI, shockingly, they focused exclusively on technology without giving a moment's thought to the impact on employment and society. It's apparent to me that Arthur C. Clarke in 1978 had more foresight than some of the experts in 2025.

Given his foresight, it's slightly surprising Clarke didn't explore the themes of super-intelligent AIs displacing people in his fiction. It would have been interesting to read a Clarke novel with societal AI change as a backdrop.

Monday, March 9, 2026

Rendezvous with Rama

I saw some news about a possible movie adaptation of “Rendezvous with Rama” and it set me thinking again about the book and what I thought about it. There’s quite a lot here, so I thought it would be worth sharing in a blog post. Let’s start with some history.

Arthur C. Clarke

Clarke (born 1917) was the pre-eminent British science fiction writer in the mid part of the 20th century with a prodigious output of novels and short stories. Globally, he was considered one of the “big three” of science fiction and he sold well in the English-speaking world and beyond.

With Stanley Kubrick, Clarke wrote the screenplay for “2001: A Space Odyssey”, which was based on his 1948 short story, "The Sentinel". The movie's psychotic HAL 9000 computer was an example of his fascination with new field of AI, though he would have been aware of the real-world “AI Winter” that came in the early 1970s.

I think it’s fair to say that much of Clarke’s fiction was driven by story rather than serious character development; many, but not all, of his characters seem a little one-dimensional and the dialog is sometimes flat. Unfortunately, parts of the misogynistic and class-based attitudes of the time leak into some of his writing (notoriously, this includes Rendezvous with Rama). To a degree, this is surprising because Clarke himself was gay, but perhaps none of us can fully escape the attitudes of our times.

Clarke emigrated to Sri Lanka in 1956, where he lived until his death in 2008.

The story of Rendezvous with Rama

In the year 2131, Spaceguard detects a large object entering the solar system which it later names “Rama”. A probe detects that it’s a 20 x 50km cylinder, obviously constructed by aliens. Because of its trajectory, the only crewed space vessel that can intercept it is the space freighter Endeavour. Endeavour’s crew aren’t explorers, they’re just a well-trained freighter crew who happen to be in the right place at the right time. The crew intercept Rama and board it.

(Rama as imagined by Nano Banana)

Inside Rama, they find several city-sized clusters of objects and a central cylindrical sea, but no life and no controlling AI. As Rama gets closer to the sun, it warms up and comes to life, meaning strange robotic lifeforms start appearing and doing things the crew don't understand. One of the crew explores deeper into the interior (in a very contrived way!) and has to be rescued, which brings some elements of danger into the novel (which up to this point has been a “space procedural”). The rescue is against the clock as the crew know their time on Rama is limited because of its flight path.

(The inside of Rama, as imagined by Nano Banana.)

Unfortunately, Rama is seen by a threat by some human groups, and the whole object is in danger, requiring the crew on the Endeavour to carefully defend Rama.

After the crew save Rama, and themselves, they leave Rama as it gets closer to the Sun. Rama then heads off towards the Magellan cloud, leaving a lot of unanswered questions.

The book was published in 1973.

Let’s turn to some of the themes in the book.

The crew

In movies like Alien, ships' crews are portrayed as space “truckers”: rude, crude, and rebellious. They have some level of training, but they’re not experts by any means. They have problems following orders and working as a team, which adds some tension and drama to the movie, but mean the crew are in trouble when things go wrong.

The crew of the Endeavour are very different; they’re highly trained, they work as a team, and they can follow orders. There’s a pointed discussion early on about avoiding heroics and working together; the ethic of quiet competence permeates the book. I’ve heard the book described as competency porn, and I agree. This isn’t a crew of space truckers, it’s like the crew of a supertanker or some other ocean-going vessel. These types of ships' crews have to work as a team and be self-reliant, making repairs underway if necessary. To the extent that a spacecraft is more like an ocean going vessel than a truck, Clarke's set-up feels more realistic.

A big part of the crew are the chimpanzees engineered to have a higher IQ that enables them to do some jobs that would otherwise be done by humans. Notably, these simps stay on the Endeavour and I think they're an underused part of the story. I also get the sense that the simps are a replacement for the AIs and robots that would otherwise run things.

(Nano Banana.)

AI?

Clarke talked a lot about AI, but in this novel, AI is conspicuous by its absence. There are no self-aware AIs in Endeavour or in Rama. I’m speculating, but I think Clarke would have seen AI go “off the boil” in the early 1970s. Perhaps he felt that after HAL in 2001, there was nowhere new to go with AI stories. Of course, by not having an AI in Rama, Clarke can keep the mystery – there’s no sentient AI that tells the humans everything they want to know.

Rama is alien

This was my second big take-away from the novel. Rama feels very alien, from the cylinder to the biots, to the way it works. Rama makes no attempt to explain itself to the crew of the Endeavour and there are no clues explaining “why”. I very much get the sense that something non-human built and operated this thing for its own purposes. The crew leave Rama with many more questions than answers.

Wonder

When I first read this as a teenager, I came away with a huge sense of wonder. What is this thing? Who sent it? Why did they send it? When I re-read it many years later as an adult, I didn’t quite get that same sense of wonder, but maybe that’s because I’m more jaded now.

Wonder seems to have fallen out of favor with sci-fi writers. I can't remember reading a recent book that gave me a sense of awe or grandeur. On the other hand, characterization and dialog are very much in favor (which is a good thing), I've read a lot of recently published books with vivid characters and dialog.

With the death of wonder, I can't help feel we've lost part of what made the genre a bit different.

Subsequent books

There are some sequel novels written by Gentry Lee. My advice: don’t read them.

Movie version

Rama isn’t an action-adventure book, but it does have some adventure themes and it does ask some thought provoking questions. It would plainly have to be a big-budget sci-fi movie.

(Nano Banana)

Morgan Freeman has spent decades trying to bring the book to the screen without success. However, as of 2021, the film is in “development” with Denis Villeneuve (“Arrival”, “Dune”) writing the script and set to direct it. Sadly, Villeneuve will work on the new James Bond movie and other projects first, so a Rama movie is still a few years in the future at best.

Overall thoughts

It’s true that you can never go back. On re-reading the book as an adult, I saw all the flaws I didn’t see as a child (including a notorious passage), and I saw little of the wonder and excitement I felt back then. The characterization is a bit flat, as is the dialog. Some of the scenarios the crew find themselves in on Rama feel a bit contrived. The politics feel off.

But….

The book offers a more intelligent view of what a first contact might be. Nothing is trying to eat you or conquer you, and nothing is trying to be your friend or show you the galaxy. The aliens just don’t care and do their alien things.

The humans in the book aren’t super men and women, but neither are they cynical individualists. They’re just competent people working together as a team.

These ideas of alien aliens and competent humans make the book different and noteworthy.

Is the book flawed? Yes. Is it worth reading? Yes. Will I be in line to see the movie? Hell yes.

Wednesday, February 11, 2026

Data is the new Lego

In 2018, I wrote a company blog post. As with most corporate content of this type, it was eventually deleted. But I liked what I wrote and I want to keep it, so I found it on the Wayback Machine and I'm reposting it here.

Reposting it serves another purpose. My post was plagiarized by someone who claimed it as their own. I want to own my work and not have other people claim it as theirs. Plagiarist have an easier time cheating if the original is hidden away on the Wayback Machine.

You can find the piece on the Wayback Machine here: https://web.archive.org/web/20190820192824/https://www.truefit.com/en/Blog/August-2018/Data-is-the-New-Lego

It was written for the company True Fit: https://truefit.com/

(Gemini)

Here's the post.

-----------

When I was a child, I used to love playing with Lego, or “Legos” as my American friends often say; my brothers and I built spaceships and trucks and houses and animals. As time went on, our creations became more ambitious, functional, and lifelike. We could each have insisted our Lego was our own, but by pooling resources, we collectively went further. Family and friends gave us Lego including unusual and hard to find bricks, which enabled us to make more accurate models. We were growing up too, and as our play became more sophisticated, we learned how to build better models.

I’m not young anymore and my bones creak on cold mornings, but I still remember playing with Lego as I go to work each morning and play with data to build models. Using data to solve real world problems, like style, fit, and size recommendations, is surprisingly like my childhood Lego memories. To build something useful you need lots of data, data diversity, and the knowledge to build the right models in the right way.

If you don’t have enough Lego bricks, the things you build aren’t realistic; the model is crude, the colors don’t match, and there are gaps. It’s the same with machine learning and computer models; if you don’t have enough data, your models are crude, and you have quantitative and qualitative errors. The history of computer modeling is rife with examples of people making bad decisions using models made with incomplete data. In dealing with style, fit, and size recommendations, not enough data means giving bad advice because your models are too crude to accurately model people and garments. This is where pooling data wins; by pooling our Lego, my brothers and I could build what we wanted; in fashion, by pooling data from many retailers, you can build better models because you have a more complete picture of consumers’ behavior and the unique style characteristics, size, and shape of garments.

To build a good quality Lego model you need a diversity of pieces – models built with just the standard 2x4 bricks are crude and inaccurate. This is where getting Lego from friends and family was so useful – we got more diverse bricks that let us build more accurate models. In fashion, you need a diversity of data on people and garments too. Simply extrapolating from the average size to plus sizes is like using 2x4 bricks for everything; one size does not fit all and you end up with something that isn’t accurate for users who aren’t ‘average’.

Simply assuming US consumers and apparel are the same as German consumers and apparel is like using the same few Lego bricks for different models; different markets need different data. Simply believing a $20,000 dress fits the same as a $100 dress is like building Lego models when the special pieces you need are missing; it’s the kind of thing you do when you don’t have the data you need. In fact, having data on $100 and $20,000 dresses lets you build richer models that make better recommendations for all dresses. The key to good modeling is having data on a diverse set of consumers and garments.

Young children make crude Lego models, the colors don’t match and the shapes are wrong; older children build working models with careful color schemes. A similar thing happens with data and algorithms. As you get to know and manipulate your data, your algorithms, and their interactions, you come to understand their limitations and you strive to build something better. As time goes by, increasing volumes of data point out the flaws in your work and you fix them– your models become better and better. In other words, the learning curve applies to building Lego and computer modeling.

It might be a brutal childhood truth, but the children with the most Lego, the best pieces, and the time to play produce the best models. The same brutal truth applies for any AI based machine learning or computer modeling project. The projects with the biggest data volumes, the most diverse data, and the best teams to use that data will produce the most accurate models. That’s why it’s fun to play with the massive data set from True Fit’s fashion Genome: it includes data from the largest number of retailers and brands; there’s a diversity of country, people sizes, and garments; and my colleagues know what they’re doing. There’s the added benefit of doing something novel and helping people find clothes they’ll love, that suit their personal style preferences, and will fit and flatter them – Lego models only make a few people happy but style, fit, and size recommendations can make millions of people happier by helping them connect more easily with the clothes and shoes that better express who they are and how they feel. Coming to work each day, it’s like playing with the world’s largest Lego set and it makes me happy.

Sometimes late at night, when it’s quiet and there’s no-one around to judge, I quietly put together Lego models. It’s a consoling and comforting reminder of my childhood, like eating ice cream, playing chase, and England losing in the World Cup. Lego has taught me a lot about data and models and collaboration. But there’s one big difference between building Lego models with my brothers and building computer models with my colleagues: I don’t fight with my colleagues quite so often.

True Fit is determined to improve the customer shopping experience by using its rich data collection from thousands of brands to provide accurate size recommendations. A larger collection of Lego increases the size of scope of projects that can be built just as a vast data collection increases the scope of customers who are provided with accurate style, fit, and size recommendations. To learn more about True Fit's data collection, called the Genome, visit here.

The perceptron

Why study the perceptron?

Perceptrons were one of the first learning systems and an important early stepping-stone to most recent AI innovations. That alone would be motivation enough to study them, however the reaction of the press, and the consequences of the hype, are a cautionary tale for us in 2026.

I'm going to share with you the why and the how of the perceptron, with some of the consequences of the hype.

Why do we care about systems that learn?

Go back to the 1950s, why would you care about a system that can learn? There’s the obvious coolness of it, but there are important real-world applications.

Photo analysts study reconnaissance photos looking for hidden bunkers or other items of military significance. The work is tiring and boring at times, but it’s hard to automate because it relies on human interpretation rather than a hard and fast set of rules. The “enemy” constantly changes how they disguise their installations, so whoever or whatever is analyzing photos must continually learn.

A similar problem occurs in post offices. If a post office wants to automate letter sorting, it has to automate reading handwritten addresses. Each person’s handwriting is different, which means creating definitive rules about letter or number formation is hard.

A learning system can adapt itself to new information and so stay productive when things change. In practice, this means it can be taught to recognize a new way a country is disguising a bunker or a new way someone is writing the number 5. It doesn’t require its creators to continually tweak settings. Of course, these automated systems can process letters or images etc. much faster (and cheaper) than human beings, which makes them very attractive.

Given the demand existed, how can you create a system that learns?

How do biological systems learn?

The obvious learning systems are biological. By the 1950s, we’d made some progress understanding how brains work, in particular, we had a basic understanding of how neurons worked, which are the lowest level of processing in the brain.

Neurons take sensory input signals from dendrites into the soma, where the input is “processed”. If the input signal crosses some threshold, the soma fires an output signal (an action potential) through an axon. Neurons learn by changing the way they “weight” different dendrite signals, so changing the conditions under which they fire.

The output of one neuron could be the input to another neuron and real brains have layers of processing.

The picture below shows the arrangement for a single neuron.

(Gemini)

My explanation of how neurons work is very simplistic and in reality, it’s much more complicated. In real brains, neurons learn together and there are other biological processes going on involving dendrites. If you want to read more about biological neurons, here are some good references:

The perceptron

In 1957, at the Cornell Aeronautical Laboratory in Buffalo, New York, the psychologist Frank Rosenblatt was studying human learning (specifically, the neuron) and trying to replicate it in software and hardware. His team built a prototype system, called the perceptron, that could “learn” in a very limited sense. The learning task was simple image classification.

(Rosenblatt and the perceptron. National Museum of the U.S. Navy, Public domain, via Wikimedia Commons)

The Mark I Perceptron input was a 20x20 photocell array; a photocell is very limited form of digital camera. These 400 inputs were fed to “association units” that weighted the inputs. The weights were set by potentiometers that were adjusted by electric motors. Importantly, the initial weights were random to avoid bias. The system summed the weights and used a simple threshold algorithm (response units) to decide the image classification, if the sum of the weighted signals was above the threshold the algorithm output a signal (a true output), if the sum of the weighted signals was below the threshold, the algorithm did not output a signal (a false output). Technically, the name of the threshold function is a Heaviside step function. If the perceptron made an error, the relevant weights were adjusted. The perceptron required 50 training iterations to reliably distinguish between squares and triangles.

(From the perceptron user manual.)

In 2026, this sounds really basic, but in 1957 it was a breakthrough. Rosenblatt and his team had demonstrated that a machine could learn and change how it “sees” the world.

References:

The perceptron theory

Here’s a simple representation of the perceptron. The inputs from the photocell are fed in and assigned weights. There’s a bias term to account for bias in the photocells, for example, the photocells might give a very small signal instead of zero when there’s no image. The weighted inputs (and the bias) are summed. If the weighted sum exceeds some threshold, the perceptron fires, if not, it doesn’t.

(The perceptron is a linear classifier, meaning it can only separates point on a hyperplane. In two dimensions, this means it can only separate points using a straight line.)

Mathematically, this is how it works.

\[u = \sum w_i x_i + b \]

\[y = f(u(x)) = \begin{cases} 1, & \text{if } u(x) > \theta \\ 0, & \text{otherwise} \end{cases}\]

In the vector notation used in machine learning, the equations are usually written:

\[y = h( \textbf{ w} \cdot \textbf{x } + b ) \]

where h is the Heaviside step function.

So far, this is pretty simple, but how does it learn? Rosenblatt insisted on starting training from a random state, so that gives us a starting point. Then we expose the perceptron to some training data where we know what the output should be (the data is labeled). Here’s how we update the weights:

\[ w_i \leftarrow w_i + \Delta w_i \]

\[ \Delta w_i = \eta(t - o)x_i \]

where:

$t$ is the target or correct output
$o$ is the measured output
$\eta$ is the training rate and $ 0 \lt \eta \leq 1$

We update the weights and try again in an iterative loop. This continues until we can successfully predict the training data set within a certain error, or we’ve reached a set number of iterations, or we’re seeing no improvement. This is similar to how machine learning systems work today.

References:

Perceptron problems

There were lots of issues with the perceptron in its original form. Let’s start with the worst: the hype.

Rosenblatt gave interviews to the press on his system and they ran with it, but not in a good way. A 1958 New York Times article was typical, the headline read “NEW NAVY DEVICE LEARNS BY DOING; Psychologist Shows Embryo of Computer Designed to Read and Grow Wiser”, with a lede: “The Navy revealed the embryo of an electronic computer today that it expects will be able to walk, talk, see, write, reproduce itself and be conscious of its existence.” Other press stories were similarly sensational and hyped the technology. The press very much set the expectation that walking, talking AIs were just around the corner. Of course, the technology couldn’t deliver what the press forecast, which helped lead to a loss of confidence.

The technical problems varied from the straightforward to the severe.

The original perceptron used a simple threshold to decide whether to fire or not, but this caused problems for training weights. Most important training algorithms use derivatives (for example, gradient descent). A simple threshold isn’t differentiable, which means it can’t be used in these kinds of training algorithms. Fortunately, this is relatively easy to fix using a differentiable function to replace the simple threshold. There are a number of possible differentiable functions, and a popular choice is the sigmoid function. (The function that decides whether to fire or not is now called the activation function).

A more serious problem is the logical limitations of the simple perceptron. As Minksy and Papert showed in 1969, there are some logical structures (most notably, XOR), you can’t build using the simple single-layer perceptron architecture. Although multi-layer networks solve these problems, the Minsky and Papert book and their papers significantly damaged research in this area, as we'll see.

This is only a summary of the difficulties the perceptron faced. For a fuller description, check out: https://yuxi.ml/essays/posts/perceptron-controversy/

What happened next

By the early 1970s, the hype bubble had burst. Minsky and Papert’s book had an impact and governments found disappointing results from funding perceptron-based projects; projects promised big results, but in reality, very little was produced. Governmental patience eventually wore thin and eventually they concluded this form of AI research wasn't worth funding. The research money went elsewhere leading to the first “AI Winter” which lasted for a decade or so.

Sadly, AI experienced another hype bubble and collapse in the late 1980s, a second "AI Winter". As a whole, AI research began to get a bad reputation.

The “AI Winters” bled talent and money away from neural network development, but research still continued. Although multi-layer networks had been developed by the 1960s, it wasn’t known how to train them until the Rumelhart, Hinton, and Williams 1986 paper “Learning representations by back-propagating errors” [https://www.nature.com/articles/323533a0] popularized the back propagation method. Convolutional Neural Networks (CNNs) using back propagation and a convolutional structure were demonstrated in 1989. With these technologies as the backbone, LLMs were developed starting in the mid-to-late 2010s. It’s only the enormous success of LLMs that has brought a flood of money into AI research and a resurgence of interest in its origins.

Rosenblatt had a wide variety of research interests, including astronomy and photometry (measuring light). By any measure he was a genius. Unfortunately, in 1971 he died at the age of 43 in a boating accident. His death was just a few years into the first "AI Winter", so he saw the hype and the subsequent bubble bursting. Sadly, he never go to see how the field eventually developed.

Thoughts on the story

The original perceptron was very much based on what had gone before, but it was a breakthrough and ahead of its time, which was part of the problem. The necessary technology wasn’t there to advance quickly. Unfortunately, the hype in the press, fed by Rosenblatt and others, set unrealistic expectations. While great for short-term research funding, it was terrible for the long-term when the hype bubble burst.

AI as a whole has been prone to hype cycles through its entire existence. It's no wonder there's a lot of discussion online about the latest AI bubble bursting. My feeling is, it is different this time, but we're still in a bubble and people are going to get hurt when it eventually pops.

Monday, February 9, 2026

Learning by hand is better than learning by AI

Accelerating learning with AI?

Recently, I've been learning a new LLM API from a vendor. There's a ton of documentation to wade through to get to what I need to know and the vendor's examples are overly detailed. In other words, it's costly to figure out how to use their API.

(Gemini)

I decided to use code gen to get me up and running quickly. In the process, I found out how to speed up learning, but equally important, I found out what not to do.

Code gen everywhere!

My first thought was to code gen the entire problem and figure out what was going on from the code. This didn't work so well.

The code worked and gave me the answer I expected, but there were two problems. Firstly, the code was bloated and secondly, it wasn't clear why it was doing what it was doing. The bloated code made it hard to wade through and zero in on what I wanted. It wasn't clear to me why it had split something into two operations, despite code gen commenting the code. Because I didn't know the vendor's API, I couldn't be sure the code was correct; it didn't look right, but was it?

Hand coding wins - mostly

I recoded the whole thing by hand the old fashioned way, but using the generated code as an inspiration (what function to call and what arguments to use). I tried the LLM calls in the way I thought they should work, but the code didn't work the way I thought it would. On the upside, the error message I got was very helpful and I tracked down why it didn't work. Now I knew why code gen had made two LLM calls instead of one and I knew what outputs and inputs I should use.

The next step was properly formatting the final output. Foolishly, I tried code gen again. It gave me code, but once again, I couldn't follow why it was doing what it was doing. I went back looking at the data structure in detail and moved forward by hand.

But code gen was still helpful. I used it to help me fill in API argument calls and to build a Pydantic data structure. I also used it to format my code. Yes, this isn't as helpful as I'd hoped, but it's still something and it still made things easier for me.

Why code gen didn't work fully

Code gen created functioning code, not tutorial code, so the comments it generated weren't appropriate to learn what was going on and why.

Because I didn't know the API, I couldn't tell if code gen was correct. As it turned out, code gen produced code that was overly complex, but it was correct.

Lessons

This experience crystallized some other experiences I've had with AI code gen.

If I didn't care about understanding what's going on underneath, code gen would be OK. It would work perfectly well for a demo. Where things start to go wrong is if you're building a production system where performance matters or a system that will be long-lived - in these cases the why of coding matters.

Code generation is an accelerator if you know what you're doing. If you don't know the libraries (or language) you're using, you're on thin ice. Eventually, something bad is going to happen and you won't know how to fix it.