Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Elegance of the ASCII Table

danq.me

Post reply on HN
Print view View original

11–20 of 189 posts

Re: The Elegance of the ASCII Table

#11

Post by gerdesj »

jiveturkey wrote: post #4

ebcdic is also quite elegant https://news.ycombinator.com/item?id=13543715

Its shit if you don't routinely speak or write English. On those grounds, I'll decry it as not only shit but purposely shit.

OK a bit over the top ... the designers of EBCSDIC had a rather tight set of constraints to deal with, none of which included: "be inclusive". Again, if I really had to be charitable (I looked after a System/36, back in the day), the hardware was rather shit too, sorry ... constrained. Yes constrained. Why should six inch fans fire up reliably after a few years of use and not need a poke after an IPL? No real dust snags and I carefully sprayed some WD40 on the one that I could get at. I have modern Dells and HPs in horrid environments that do better with shitty plastic fans.

EBCDIC is not elegant at all unless excluding non English characters in an encoding system is your idea of elegant.

According to this: https://en.wikipedia.org/wiki/EBCDIC it expended loads of effort with dealing with control eg: "SM/SW" instead of language.

ASCII and EBCDIC and that basically say: fuck you foreigners!

We now have hardware that is apparently capable of messianic feats. Let's do the entirety of humanity some justice and really do something elegant. It won't involve EBCDIC.

Re: The Elegance of the ASCII Table

#13

Post by th0ma5 »

I heard someone describe the ASCII table as a state machine. Guess I could understand that as a state machine needed to parse it? This is surprisingly hard to search for but I was wondering if anyone knows what they were talking about.

Re: The Elegance of the ASCII Table

#14

Post by pwg »

jolmg wrote: post #10

> So when you’re reading 7-bit ASCII, if it starts with 00, it’s a non-printing character. Otherwise it’s a printing character. > The first printing character is space; it’s an invisible character, but it’s still one that has meaning to humans, so it’s not a control character (this sounds obvious today, but it was actually the source of some semantic argument when the ASCII standard was first being discussed). Hmm..…

You also have to keep in mind the "interface" for 1962-1968. The printer teletype machine.

The "control codes" were to "control" the printhead. So "carriage return" meant move the "print carriage" back to the left margin. "New line" meant move the paper platen one line height of rotation to move the paper to the next line. In that context, "back space" was "move print head one space left" (rather more like a "reverse space"). The article does mention that there was some debate about whether space should be considered "printable", but if you consider a mechanical printer, as the head is moving to the right and banging out characters onto the paper, the spaces between words do, sort of, look like "printables" (of a sort, a "print nothing" character as it were).

Tab's being control characters then make a bit more sense, in that they cause the printhead to jump some fixed distance to the right.

The article stated why DEL is where it is (all ones) -- so that for punched paper tape, one could get a punch-out of every position, which was then interpreted as "nothing here" by the tape reading machine.

As for typewriters, no, none had a "black box" blot out key. Correction (for typewriters without built in correction tape) was one of: retype the page, apply an eraser (and hopefully not damage the paper surface too much) then retype character and continue, or apply correction fluid (white-out) and retype character and continue.

For those typewriters with built in correction tape options (at least some IBM Selectric models, possibly more) the typewriter would retype the character using the "white-out" ribbon, then retype the replacement character using the normal "typewriting" ribbon.

Re: The Elegance of the ASCII Table

#15

Post by thaumasiotes »

BobbyTables2 wrote: post #12

I always lament that since at least 1980s or so, it seems the vast majority of the control characters were never used for their intended purpose. Instead, we crudely use commas and tabs as delimiters instead of something like RS (#30).

That's because the intended purpose is either useless (for machine control characters) or useless and logically impossible (for delimiters).

What do you do if you have a record that includes a record separator character? Given that you have this problem anyway, why do you want a character dedicated to achieving the same thing that a comma achieves?

Re: The Elegance of the ASCII Table

#16

Post by penteract »

thaumasiotes wrote: post #15
BobbyTables2 wrote: post #12

I always lament that since at least 1980s or so, it seems the vast majority of the control characters were never used for their intended purpose. Instead, we crudely use commas and tabs as delimiters instead of something like RS (#30).

That's because the intended purpose is either useless (for machine control characters) or useless and logically impossible (for delimiters). What do you do if you have a record that includes a record separator character? Given that you have this problem anyway, why do you want a character dedicated to achieving the same thing that a comma achieves?

The record separator isn't on people's keyboards, so it's less likely to show up where it's not expected. Also it's less likely to legitimately occur in something like a name, so there are many users of CSVs who can say they will never need to consider data containing a record separator, and they will be right more often than those who never consider data containing a comma.

Of course, the fact that record separators aren't on keyboards is probably why CSVs use commas.

Re: The Elegance of the ASCII Table

#18

Post by EvanAnderson »

pwg wrote: post #14
jolmg wrote: post #10

> So when you’re reading 7-bit ASCII, if it starts with 00, it’s a non-printing character. Otherwise it’s a printing character. > The first printing character is space; it’s an invisible character, but it’s still one that has meaning to humans, so it’s not a control character (this sounds obvious today, but it was actually the source of some semantic argument when the ASCII standard was first being discussed). Hmm..…

You also have to keep in mind the "interface" for 1962-1968. The printer teletype machine. The "control codes" were to "control" the printhead. So "carriage return" meant move the "print carriage" back to the left margin. "New line" meant move the paper platen one line height of rotation to move the paper to the next line. In that context, "back space" was "move print head one space left" (rather more like a "reverse…

> The article stated why DEL is where it is (all ones) -- so that for punched paper tape, one could get a punch-out of every position...

I saw an analogous use of backspace on some OS I ran into 30 years ago cruising around either Tymnet or TELENET. (I wish I could remember the OS...)

The password prompt assumed local echo. After entering a password the host would send a series of backspaces and various patterns of characters (####, **, etc) to overprint the locally-echoed (and printed) characters.

Re: The Elegance of the ASCII Table

#19

Post by thaumasiotes »

penteract wrote: post #16
thaumasiotes wrote: post #15

Earlier quoted context omitted.

That's because the intended purpose is either useless (for machine control characters) or useless and logically impossible (for delimiters). What do you do if you have a record that includes a record separator character? Given that you have this problem anyway, why do you want a character dedicated to achieving the same thing that a comma achieves?

The record separator isn't on people's keyboards, so it's less likely to show up where it's not expected. Also it's less likely to legitimately occur in something like a name, so there are many users of CSVs who can say they will never need to consider data containing a record separator, and they will be right more often than those who never consider data containing a comma. Of course, the fact that record separators…

> Also it's less likely to legitimately occur in something like a name, so there are many users of CSVs who can say they will never need to consider data containing a record separator, and they will be right more often than those who never consider data containing a comma.

No, they'll be right exactly as often, 0% of the time.

But their mistake will show up less frequently, causing more problems when it does.

As soon as it's possible for some of your data to come from someone else's dataset, you're guaranteed to have to accommodate record separators within your data as well as within the metadata. You're better off using a system that plans for this inevitability than one that pretends it can't happen at all.

Re: The Elegance of the ASCII Table

#20

Post by EvanAnderson »

BobbyTables2 wrote: post #12

I always lament that since at least 1980s or so, it seems the vast majority of the control characters were never used for their intended purpose. Instead, we crudely use commas and tabs as delimiters instead of something like RS (#30).

I did some ETL work that used the ASCII delimiter characters. It was very enjoyable. I didn't have to worry about escaping or parsing escaped strings. The control codes were guaranteed to be illegal in input. It was refreshing.
Post reply on HN