The Great Curly Brace Trace Chase (2003)
web.archive.org
web.archive.org
(I found it while searching around for the year on this article. He seems to have updated it until 2003.)
A few interesting mentions of Bemer in the HN archives:
https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
Because the symbols used by IBM were available in all later character sets for computers, unlike the traditional mathematical symbols, almost all programming languages introduced after 1965 have used either the IBM symbols or symbols derived from them ("&&", "||").
The use of backslash was suggested at about the same time, but the PL/I alternative of using a single dedicated character was more convenient.
Unlike PL/I, IBM APL\360 used the traditional logical symbols, like Algol, but APL used a special character set anyway, so 2 more or 2 less special characters did not matter.
I looked at https://networking.ringofsaturn.com/Web/syntax-across-langua..., which is a great resource, but doesn’t even mention Algol in that section.
This begs the question: where did curly braces come from originally? Parentheses are common in prose writing, but I can’t think of why type writers or computers would have all had {} characters if there weren’t a history of their use. Wikipedia doesn’t seem to mention any literary history either (in fact it reference this article as their introduction to ASCII only).
I suppose maybe set notation introduced them first? But I know that math notation we use today isn’t always the notation that the inventors used when first proposing ideas, so it’d be interesting to learn who first used curly braces for sets, and whether they invented that symbol or whether printing presses already could print them.
And I'm thinking — why not one separator and the byte that follows indicates Unit/Record/Group/File/etc.?
Amazing though that we know the moment and the person (and the reason) that specific ASCII characters were added.
Were we defining ASCII for the first time now, I suspect the BELL control code would be gone — perhaps replaced by the smiley-face?
I started digging into it, a eventually worked out that some system at the start of the chain was using the ASCII US and RS characters to separate the notes! Each note would have the format of
timestamp␟username␟note␞timestamp␟username␟note
and so on. Then, through some chain of black boxes I never got to see, those ASCII values were converted into the visual ones I used above (U+241E and U+241F), then those were misinterpreted into Latin1 or some other non-Unicode encoding. What came out the other end were the jumbled messes I saw.I ended up just searching and splitting on those messy characters to recover the structured format of the notes. (They were all dumped into a single field in the SOAP record. I hate SOAP enough as it is, but was amazed how our systems managed to ruin it even more :)
It's useful when there's a chance of power loss or program crash during logging and it's important to recover all the written records.
With conventional logging that terminates each line with LF, if the write is interrupted, after the program restarts the next logged line is merged with the previous part-line. The result is the first line of each log file after each restart is junk and fails to match whatever patterns are scanned for later.
When each line begins with RS and ends with LF, lines that are written whole are always found later.
That can't be done; the concept of a "record separator" character already assumes that there is a value that can't occur within the data. If you play along with that, you're not making good use of anything.
You're better off using commas and being forced to constantly confront the fact that tons of data contains commas than using a byte value that hides the problem slightly better than commas do.
But, modern text editors almost universally can't even manage to provide a coherent means of editing boldface text (cursors always get stuck on the wrong side of a hidden tag). So I doubt such a feature would have been well supported, even had it existed at all.
However that requires a smarter program to display the data the intended way. CSV files, and their cousin of sorts TSV files, can often be sufficiently read both raw as well as on line printers.
That's an extra byte ... a whole extra byte! 20 odd years later my ZX80 had 1KB of RAM and a portion of even that was unavailable for the end user. My C-64 had a whopping err 50ish? KB usable RAM. My 80286 1MB. etc. This laptop has 32GB.
I remember my mum getting her first electronic typewriter. It went bing at the end of the line to warn you, just like the old manual jobbies. I guess that was BEL in action. Later models had a buffer that you typed into and then it would spew text onto the paper when it knew what to do with your text to avoid splitting words or whatever lowly skills it had with typesetting.