Say, has anyone ever tried BASIC's non-consecutive numbers for spreadsheet coordinates? We programmers always laugh at spreadsheet's use of coordinates ("like machine code without assembly") but few users avail themselves of features to name ranges / structured/hierarchical data etc. But there are real annoyances with what-you-see-is-what-you count consecutive coordinates: They mostly shift correctly on insertions/deletions, BUT one needs to grok $A4 vs. B$7 notation, which I suspect many don't. Getting range E3:F34 boundaries for formulas exactly right is always a hassle. So I wonder if features like named ranges are "premature formalization" then maybe "structured numbers" in the BASIC's style could serve as more accessible "semi-formalization"? BASIC users quickly learnt conventions like "increment by 10, start functions on hundreds, big modules on thousands". And this allowed them to avoid re-numbering almost entirely! (This was good UX in teletype line-editor era 🖨️, and of course now we have full-screen editors and can insert/delete — no need to "increment from 10 to 20 so you can later insert 15". But a 2nd aspect that imho was really genius was the numbers were stable, helping your brain 🚲🧠. Your transcript 📜 had partial `LIST`ings, followed by chains of edit actions (poor man's git) + REPL experiments, and the fact that line 60 remains 60 throught helped you mentally interpret that history — making you a better debugging detective 🕵️‍♀️. It's insane to remember what

GOSUB 437

means; easier if you assign semi-systematic round

GOSUB 2100

.) So, suppose spreadsheets let you use higher numbers/column names freely, by skipping display of unoccupied rows/columns. • If you have a long table that might grow, you won't put

=SUM(...)

computation directly beneath it; you put it at next 100 or 1000 — but it will still display close to its bottom. And you can type the range as

10:99

from the start. • With some foresight allocating "big enough" ranges for tables, you might never run into situations where

$B7

vs.

B$7

matters. (This means spreadsheet should become smarter yet in renumbering on insert/delete — do shift rows/columns, but stop at next unoccopied "moat".) • To introduce users to the idea, don't show consecutive numbers/letters. Even in an empty spreadsheet, after some rows/columns, skip to some far-away numbers like 100 and 1000! • Perhaps it might also subsume the feature of "freezing" some rows/column from scrolling? mockup below has one fake "scrollbar" to suggest a portion could be scrolled separately. attaching a mockup to this thread (drawn in a regular spreadsheet😉)

I love anchors, as my brain doesn't like it when things move around and aren't "where I left them". I want to add a

table

type to our language, like you can have a table in a spreadsheet (at least in Excel), which gives you this sub-thing that is a logical unit and structure, which can grow or change shape. On the viz side, the trick is how to improve this. Today, at least in Excel, you have the worksheet model, and that's all you get for UI (bear with me). e.g. you can't make a table and pop it up in it's own window. Worksheets are a flat stack, rather than something like MDI child windows. But what if you could do that, maybe something like Oberon or totally free-form. If you want to merge them all into a flat worksheet, their range IDs provide the layout positions, but they also have names and can be addressed relatively that way as well.

An interesting historical point is that the earlier language JOSS (from Rand Corporation, quite similar to BASIC except for syntax detaid) used floating point line numbers, which means that already written statements didn't need to be renumbered.

Though limited in many ways, I do like how Numbers on macOS can use column/row headers as names in formulas.

Thinking more, thes might avoid relavite/absolute

B$4

notation due to relocation, but it'll still be needed for replicated formulas when mixing cscalars/vectors/matrixes :-( E.g. if you have a column of prices * scalar tax rate stored in single cell, the reference to that cell must be absolute.