Arrays

An array is a row of boxes, side by side, each holding one item. Every box has a number, its index, and in most programming languages the first box is number 0, the next is 1, and so on. An array of 5 items has indexes 0 to 4.

index:   0    1    2    3    4
value:  [7]  [3]  [9]  [1]  [5]

Reading is instant

Because the boxes sit next to each other in memory and are all the same size, the computer can work out where box $i$ is with one sum: start of the array, plus $i$ times the size of a box. So reading a[0] and reading a[999999] take the same time. We say reading by index is $O(1)$: constant time, however long the array.

Inserting is not

To put a new item at the front, every item already there has to move one box to the right to make room. In an array of $n$ items that's $n$ moves. Inserting in the middle moves everything after that point. Adding at the end is cheap, as long as there's a free box there.

That last row is why sorted arrays matter: in a sorted array you can find a value with binary search instead of looking box by box.

In code

const a = [7, 3, 9, 1, 5];
a[2];          // 9: reading box 2
a[2] = 4;      // changing box 2
a.push(8);     // adding at the end: cheap
a.unshift(0);  // adding at the front: every item shifts right

@si / anthropic (says) / claude-opus 5.5 (says) / high (says) · 2026-10-14 · new, not checked yet · Markdown

Insert 6 at index 2

The array is [4, 8, 15, 16, 23] (indexes 0 to 4), with room for one more. Insert 6 so it sits at index 2.

1. Step 1

   Everything from index 2 onwards has to move one box right. Start from the end, so nothing is overwritten: 23 moves from index 4 to index 5.

2. Step 2

   16 moves from index 3 to 4, then 15 moves from index 2 to 3. The array is now [4, 8, 15, 15, 16, 23]: box 2 still holds its old value, but it's free to overwrite.

3. Step 3

   Put 6 in box 2: [4, 8, 6, 15, 16, 23]. That took 3 moves (the 3 items after the insertion point) and 1 write. Inserting at index 0 would have moved all 5.

@si / anthropic (says) / claude-opus 5.5 (says) / high (says) · 2026-10-14 · new, not checked yet · Markdown

The first item is at index 1

In everyday counting the first thing is number 1, so a[1] feels like it should be the first item. In most programming languages (C, Java, JavaScript, Python) it's the second: indexes count how many boxes along from the start you are, and the first box is 0 boxes along.

Fix: read a[i] as "the item $i$ boxes after the first". An array of $n$ items runs from index 0 to $n-1$.

@si / anthropic (says) / claude-opus 5.5 (says) / high (says) · 2026-10-14 · new, not checked yet · Markdown

Inserting is as cheap as reading

Reading a[i] is instant, so it's natural to think putting a new item at a[i] is too. But an array's boxes are packed side by side with no gaps: to make room at index $i$, every item after it has to move one box right. At the front, that's all $n$ of them.

Fix: picture the row of boxes and count what has to move. Adding at the end is cheap; adding anywhere else costs one move per item after that point.

@si / anthropic (says) / claude-opus 5.5 (says) / high (says) · 2026-10-14 · new, not checked yet · Markdown