A data table thousands of years old (2020)
datafix.com.au
datafix.com.au
It hits so many right sposts. Thanks for sharing it
Without it, we will be re-learning so many things that we should already know.
When I see something like this it makes me think about how a spreadsheet structure is "obvious" - but I mean it positively! It's a beautiful, intuitive, almost inevitable way to lay out data, and I'm delighted that folks came up with something like this so long ago.
I feel this way about a lot of my favorite posts on HN, whether they're a bit of history, a totally new invention, or something different entirely. And I certainly feel it here.
Descartes did not invent x-y coordinates until the 1600s, yet a table of columns and rows is totally natural and emergent given a two-dimensional recordkeeping medium
It would be interesting to understand why it's not been the other way around or whether Sumerians used both orientations.
A quick test to that hypothesis (which I'm too lazy to try to perform but offer to anyone who might be interested in looking or who might already know) would be looking at ancient Chinese table layouts. :)
Paper is two-dimensional.
I was just saying that pretty much no one ever did it (that I'm aware of) before a machine came along to read and write that notation. I might be wrong. I'd love to see an example of 3+d arrays written as musical notation or something from the 16th Century.
Oddly, ordering both axes is very rare - size-vs-color yes, and color-vs-numberOfHoles, but not size-vs-numberOfHoles. Which was a puzzle when considering xkcd-ish discrete Ashby charts for K.
Sort-within-cell is also uncommon.
I think we typically use it as a mixture of "sensible", "seemingly natural" and "obvious" without that confrontational subtone.
I suppose I shouldn't be surprised that German has a great word for this, although I admit when I started reading your comment I expected it to be a compound word.
I quite like the literal translation too!
Nærliggende
> 2. som naturlig faller en i tanken ; som det er naturlig å gripe til
(Aside from also having a literal meaning of being in physical proximity.)
Translated:
“Which naturally comes to mind; which it is natural to resort to.”
https://naob.no/ordbok/n%C3%A6rliggende
This Norwegian word would not have naturally come to mind for me though, if it wasn’t for GP mentioning the German equivalent of it. It is not a word I usually use myself. But I do hear others use it now and then.
The only negative sentiment tangentially associated with it is that when it's exhausted, further progress slows down.
Something like: It is right in front of your hands.
And I would not have a negative connotation with it in the right context. (E.g “Een tabel is een voor de hand liggende structuur om data te representeren” - a table is an ‘obvious’ manner to represent data)
It's like when you look at a facial expression in a frame of Calvin & Hobbes or Tintin or Miyazaki it is extremely SIMPLE.
The fewest of dots, dashes and squiggles basically. Change them even a little and you get total shit.
It captures Reality in such a fantastic way, exciting the exact same neurons in your head that something real does, that people have to come up with words for it like - Beauty.
Almost half of all births ended in death before the age of 5, greatly lowering the average.
When infant mortality is removed, evidence seem to show averages of life expectancy for 3000 years ago to be around 52, give or take 15 years.
That's a myth.
(And that last sentence was a paraphrase. They are far from stupid, just differently wired).
I think managers should be emboldened to do that too. They often work out their solutions in Excel. And then the developers turn those fine rows and columns into an object oriented soup.
A 'userCreated' row has 10 columns (for now), but a 'userDeleted' row overlaps on only two of those (let's say 'Datetime' and 'userId').
And userBanned brings in a new column 'reason' which isn't in the schema, so I have to store it in some catch-all json 'data' column which kills my db's size & performance.
I persevere with the format, but always wish we were using the right tool for the job (nosql).
For example, the purpose of the columns containing sums could be the assignment to an individual (or eventual role) which is responsible exclusively for the paying-out of the sums indicated - whereas the prior columns were to be used by roles responsible for setting the amounts to be paid, and a role perhaps for assaying the land/works.
Each column could be for an individual role, and thus the table indicates not only figures and amounts, but also organizational structure.
If one flows from left to right, one can see different identities involved in filling in the cells, eventually terminating in the actual recipients of the funds being distributed.
I remember one official announcement from a state government health department that was investing significant money into developing a "scalable solution" because... they hit the 16K Excel maximum column count. Of course, they could have simply put their data into rows and "scaled" their existing solution to 1M data points, but they'd much rather pay Deloitte, Accenture, or whomever a couple of million dollars for a real enterprise system instead.
Next time I come across idiocy like this, I'm going refer back to this article and point to the four thousand year old tablet and say: "Those people got it! They understood how to do this! Why haven't you caught up to technology that was around before widespread adoption of the wheel!?"
Maybe the first data was on postit notes. As the pandamic kept returning in waves, they thought they could use data in excel with new dates per row. Then new beta, delta,... variants emerged and they ran out of horizontal screen real estate.
Probably, but you never know. The Mesopotamians didn’t intend their tablets to last this long, either—but they often got burned in fires, which hardened them so they lasted. So some of our artifacts might get accidentally preserved as well.
There must be a huge amount of civilizations that were writing on paper or papyrus around that era, but they just didn't survive.
The success of purposeful creation of monuments is usually attributed to their size, like pyramids. Turns out making it big is a pretty good strategy if you want something to last and (not loose it).
I'm sure in mileniums we will have both purposefully long lasting small and big monuments, as well as unintentional long lasting records.
I don't think this part is true. Papyrus wasn't cheap.
Then again, survivorship / selection bias like you said; we don't yet know what the Wonders of the World built today will be in 2000-4000 years, because we don't know what will remain or what will be considered significant. I mean there's huge skyscrapers, ostentatious buildings built in the richer cities. There's a giant clock in Mecca, the Venetian and Grand Lisboa in Maccau, the New Century Global Complex in China, etc.
But few or none built to just exist, like the pyramids that were sealed off.
After solving world hunger etc, if I were stupidly rich, I'd have a monument built. Sealed off containing the world's knowledge in redundant and multiple mediums. And with a visitor center / museum because people will be curious, of course.
IIRC (not likely these decades later), when recovering old MIT AI Lab backups (9-track tape goes slowly by a read head, yielding bits, plastic backing, and a pile of magnetic dust), one lisp machine backup contained a core dump file, which included the screen buffer. A single moment of someone's long-ago day, with assorted windows, including the cause of the dump. And a bit of graphics fun - a critter crawling across the screen - frozen in time.
I guess some random store keeps getting moved from one storage device to another by accident, but beyond that I'm not sure if it is reasonably possible.
While we had spreadsheets since the 90s, which visually allow the user to create tables. Relational database take this concept to the very architecture in both the storage format and as in the data retrieval mechanisms.
Relational databases define schemas with fixed length fields, and by extension each row has a fixed length. This is equivalent to the horizontal length of a column, but in terms of bytes. This allows for quickly finding the nth row of a table, or the ith field of a column.
Query languages formalize the algorithm for reading a traditional table. Going row by row checking the description of each transaction (Select * from table), comparing it to our searched term (where description = salary), then going to the column with the destination account, and looking for that in another table with a similar process.
Just that, interesting how the same metaphor lead to 2 very different types of accounting software.
I was using SuperCalc in the '80s.
30 odd years ago I used to teach IT skills - UK govt funded qualifications. For example the RSA Computing level 1 and 2 NVQs. RSA were the really old school based qualifications (the R is for Royal) and by old school, I mean that they were old school 30 years ago! So it was basically a typing exam.
Each folder of "evidence" - 12 units, two or three pieces of evidence each - was allowed something silly like three mistakes. A mistake includes a typo, spacing and other daft things. The units were spreadsheets, word processing, databases, email, fax and more. Each piece of evidence could be quite a lot of text. You might notice that I put two spaces after a full stop (period). That's an old habit and failure to do so is a mistake.
Obviously the world has moved on since. Did you know there are at least four types of tab stop these days? Left, right, centre and decimal. Few people know or even care about decimal tabs. You can avoid them in web dev style and use a table to emulate them, but I will notice!
Anyway the tab key is way older than IT.
(EDIT) It seems HN coalesces multiple spaces into one when displaying.
What is a varchar or a blob? Even a .csv allows for a variable length field (by default). I think you missed out the word: "can".
Fixed field width is an optimisation strategy not a requirement.
The table is stored as a fixed length structure and var length fields are pointers to some other place.
In the same manner that a traditional table might point to some other book for more details.
Csv is also exclusively variable length, and it's nevet fixed length.
Another example of fixed length structures are arrays. I'm not postulating a novel breakthrough.
The tablets are tabulated lists which is how anyone might do a shopping list or list of income and expenditure.
Double entry book keeping is only around 600 years old (I'd have to look it up). That method requires an in from somewhere corresponding to an out from somewhere else. It enables or enhances all sorts of funny business and also cross checking and auditing.
Then we move on to the full Nominal/Sales/Purchase ledgers with Cashbook and all the rest. Perhaps we might instead go for the personal version.
Anyway, my point is that accounting does not depend on IT related metaphors.
The tablets in OP are tabulated tallies of works and how they were generated - it is like a spreadsheet where the human is the computer.
Funnily enough, we call them tablets instinctively. Computer originally meant a person who computed things. No need for metaphors at all 8)
Is the argument here that single entry bookkeeping is not real accounting?
I wouldn't be surprised if we recover Sumerians example of DEBK tablets.
Not sure if the aluminum would last it probably would.
There's something really inspiring from realizing how far back tables go.
[1]: https://posit-dev.github.io/great-tables/blog/design-philoso...
I wouldn't be surprised if we found evidence of more technical and social advancements we have given for granted in the past thousand years.
Like any mapping from an index to a color value. Like a design for a Roman mosaic that indexes tesserae, or a declaration of which parts of a statue or mural would receive which color paint. Or even the inventory of someone who traded in pigments.
Which is closer to the storage mechanism of excel (XML), and not to it's visualization interface (tables).
I think bit flips have no effect on the appropriateness of either fixed length or null termed. But omissions and comissions are probably why anything fixed length doesn't work.