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

31–40 of 189 posts

Re: The Elegance of the ASCII Table

#31

Post by theamk »

jiveturkey wrote: post #4

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

It's really not.

In base-2 machines, the letters are mixed with punctuation, which is pretty horrible design which makes simple things complex, and does not actually bring anything new to the table.

In BCD machines it is slightly better, except letters aren't contiguous either - row 0 is bad, but it's the extra space between R and S which is really ugly. And it's unusable with BCD operations anyway, as high nibble values are used extensively.

Naive sorting simply does not work... lowercase before uppercase, punctuation in the middle of the alphabet, numbers after letters.

I see no elegance there, it's like the worst example of legacy code.

Re: The Elegance of the ASCII Table

#32

Post by kragen »

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..…

del is not a printing character. it's a control character. if you run a paper tape full of del characters through a teletype it does not print anything. it has to have that bit pattern, even though it greatly complicates the mechanics of the teletype (which has to do all the digital logic with cams and levers) because that way it can be punched over any character on the paper tape to delete it

a figure caption in this page says 'This is a historical throwback to paper tape, where the keyboard would punch some permutation of seven holes to represent the ones and zeros of each character. You can’t delete holes once they’ve been punched, so the only way to mark a character as invalid was to rewind the tape and punch out all the holes in that position: i.e. all 1s.' which is mostly correct, except that it wasn't a historical throwback; paper tape was perhaps the most important medium for ascii not just in 01963 and 01967 but probably in 01973, maybe even in 01977. teletype owners today are still using paper tape that was manufactured during the vietnam war, where it was used in unprecedented volume for routing teletype messages by hand

the dominant early pc operating system, cp/m (if it's not overly grandiose to call it an 'operating system') had system calls for reading and writing the console, the disk, and the paper tape punch and reader. when i hooked up a modem to my cp/m system to call bbses, i hooked it up as the punch and reader

Re: The Elegance of the ASCII Table

#33

Post by penteract »

thaumasiotes wrote: post #28
penteract wrote: post #27

Earlier quoted context omitted.

> 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. Enough people use CSVs (and have limited, small-scale use-cases) that I'd be willing to bet "less frequently" means never for at least 1% of people who use CSVs. I don't know whether the chance of no problems is worth the increased difficulty of problems that do occur - consid…

> considering that balance feels a bit silly because if you're aware there could be a problem in a context where you could choose between commas and record separators, you could just add validation or escaping. As soon as you have validation or escaping, having a record separator character loses its entire purpose. The existence of the character is predicated on the idea that you don't have to do that, and that idea…

> As soon as you have validation or escaping, having a record separator character loses its entire purpose. The existence of the character is predicated on the idea that you don't have to do that, and that idea is false.

I disagree with this - the data needs to be stored somehow, and while other characters (like comma) can be used, having a dedicated character can help - for example if the data might legitimately contain commas or newlines but not unit separators or record separators, then escaping isn't needed if you use unit/record separators (although validation is still necessary).

Re: The Elegance of the ASCII Table

#34

Post by gumby »

I wish the author had included the full ascii chart in 4 bits across / 4 bits down. You can mask a single bit to change case and that is super obvious that way.

The charts that simply show you the assignments in hex and octal obscure the elegance of the design.

Re: The Elegance of the ASCII Table

#35

Post by penteract »

yardshop wrote: post #23
penteract wrote: post #16

Earlier quoted context omitted.

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…

In the DOS days, you could "type" control characters by pressing Ctrl and the corresponding letter key, Ctrl+M is Carriage Return, Ctrl+H is Backspace, Ctrl+Z is End Of File, etc. It was probably possible to type an RS with Ctrl+Shift+. and the others with similar combos.

In a desktop linux terminal, Ctrl-^ or Ctrl-~ work for me. In a tty, I need to press Ctrl-V before them.

Re: The Elegance of the ASCII Table

#37

Post by AdamH12113 »

gumby wrote: post #34

I wish the author had included the full ascii chart in 4 bits across / 4 bits down. You can mask a single bit to change case and that is super obvious that way. The charts that simply show you the assignments in hex and octal obscure the elegance of the design.

The third and fourth columns of the table are only a single bit apart from each other. If you mentally swap the first two columns, you get a Gray code ordering of the most significant bits, which is pretty close to what you're looking for.

Re: The Elegance of the ASCII Table

#39

Post by kalleboo »

gumby wrote: post #34

I wish the author had included the full ascii chart in 4 bits across / 4 bits down. You can mask a single bit to change case and that is super obvious that way. The charts that simply show you the assignments in hex and octal obscure the elegance of the design.

It was at some point looking at a chart like that where it also dawned on me where the control codes like ^D, ^H, ^[ etc came from

Re: The Elegance of the ASCII Table

#40

Post by AdamH12113 »

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?

> What do you do if you have a record that includes a record separator character?

You use the ASCII escape character (0x1B), which is designed for exactly that purpose.

Post reply on HN