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

161–170 of 189 posts

Re: The Elegance of the ASCII Table

#161

Post by aff0 »

augusto-moura wrote: post #160
fitsumbelay wrote: post #136

Earlier quoted context omitted.

strange: on MacOS 14.5 I get output for `man ascii` but `ascii` goes "command not found"

Not sure why anyone would downvote your comment, because it is a genuine question `man` is basically manual documentation on anything on your system, not only commands. Most commands do have a manpage for them, but it is not a requirement. The argument of the command is just the file name for the document

Indeed `man ascii` (on MacOS but the same for Linux for the most part) shows the manpage for 'ASCII(7)' - the '7' denotes the section of the manual the manpage is from. If you use `man man`, you can see the section numbers and names, e.g. Section 1 General Commands, 5 File Formats, 7 Misc Info, 8 System Manager's Manual. If a word, e.g. 'crontab', has multiple entries in different sections, then you might have to specify the section you want, e.g.`man crontab` shows the crontab(1) (General Command) and use `man -s 5 crontab` to see the crontab(5) (File Format). `apropos crontab` will show entries related to crontab, i.e. cron(8), crontab(1), and crontab(5).

Re: The Elegance of the ASCII Table

#162

Post by [deleted] »

nikau wrote: post #84
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..…

Logically space maps to a character people use with pen and paper unlike tab

[deleted]

Re: The Elegance of the ASCII Table

#163

Post by WalterBright »

mnau wrote: post #158
WalterBright wrote: post #156

Earlier quoted context omitted.

I'm sure that books can be printed in your language without any need for semantic information in the characters.

Yes, they can. Is it a problem that they do? I don't think so. Using semantic symbols seems far better option. Most fonts simply map multiple codepoints to a single glyph while dealing with all fun stuff like ligatures and all fun from GSUB tables (and fun company tables in fonts). Honestly, I see semantic information as an absolute win and good choice. If unicode didn't contain it, it would have to be somewhere else…

> Using semantic symbols seems far better option

Except it doesn't actually work. 'a' has a zillion different semantic meanings, all dependent on context. There is no crisis with somebody reading a book and misunderstanding which particular semantic meaning it has, because it is inferred from the context.

Semantic meaning always comes from context, and Unicode cannot fix that. People can use the mathematical code point for 'a' instead of the text 'a' and the semantic Unicode meaning is meaningless because the reader will see, like the letter 'a' in because, that it is a text meaning.

The only thing you get with multiple code points for 'a' is you can send out multiple identical appearing texts, but are different Unicode, so you can determine who leaked the memo.

Unicode's extremely limited markup ability helps nobody.

Re: The Elegance of the ASCII Table

#164

Post by ygra »

yencabulator wrote: post #131
WalterBright wrote: post #52

Too bad we now have Unicode, an elegant castle covered with ugly graffiti and ramshackle addons. For example: 1. normalization 2. backwards running text (hey, why not add spiral running text?) 3. fonts 4. invisible characters 5. multiple code points with the same glyph 6. glyphs defined by multiple code points (gee, I thought Unicode was to get away with that mess from code pages!) 7. made up languages (Elvish? Come…

I can't wait for when the majority of Unicode codepoints/glyphs are emojis that are no longer fashionable! That'll be a really weird relic of history, later.

It would probably be like other letters like þ that are no longer fashionable in some languages. Or not-so-small parts of Hanzi. Or completely dead scripts.

That being said, Emoji are a drop in a bucket when it comes to the number of encoded code points. Nicely enough, by encoding emoji outside the BMP, you can now use characters from astral planes in a lot more places without software breaking.

Re: The Elegance of the ASCII Table

#165

Post by snvzz »

Gormo wrote: post #140
snvzz wrote: post #75

The ASCII table is defective; it is missing a dedicated code for newline. CR and LF aren't dedicated, and have precise cursor movement meanings, rather than being a logical line ender. There was a proposal in the 80s to reassigning the -otherwise useless- VT (vertical tab) character for the purpose. Unfortunately unfruitful.

> Unfortunately unfruitful. Fortunately unfruitful, since if it had gained adoption, there'd be a mix of three different line endings (and combinations thereof) in widespread use, instead of two.

>there'd be a mix of three

We already got four. \n, \r, \n\r and \r\n.

Re: The Elegance of the ASCII Table

#167

Post by bandie91 »

EvanAnderson wrote: post #42
theamk wrote: post #29

Earlier quoted context omitted.

Could you do the same with TSV? A lot of datasets can either prohibit tabs in data, or convert it to spaces in early ingestion.

TSV is a joy compared to CSV, for sure. CLI tools that output TSV are what immediately spring to mind.

shameless plug: https://repo.or.cz/hband-tools.git/blob/HEAD:/tabdata/README...

Re: The Elegance of the ASCII Table

#168

Post by eviks »

p_l wrote: post #138
news_to_me wrote: post #119

Earlier quoted context omitted.

> "a + ogonek accent" and another (properly) sent "a with ogonek" (these print the same but are semantically different!) How can these possibly be semantically different? Isn’t the point of combining characters to create semantic characters that are the combination of those parts?

There's a semantic difference between "accented letter" and "different letter that happens to visually look like another language's accented letter". "Ą" in polish is not "A" with some accent. And the idea behind unicode was to preserve human written text, including keeping track of things like "this is letter A1 with an accent, but this is letter A2 that looks visually similar to A1 with accent but is different sema…

But it is precisely "a with some accent", you just have two ways to encode it for

Re: The Elegance of the ASCII Table

#169

Post by eviks »

WalterBright wrote: post #156
mnau wrote: post #91

Earlier quoted context omitted.

As someone that whose native language isn't representable purely by ASCII, I celebrate it. Plus the first 128 codepoints are same as ASCII in UT-8. Is Unicode kind of messy? Sure, but that's just natural consequences of writing systems being messy. Every point you made was for a sensible reason that is in a scope of Unicode mission (representing all text in all writing systems).

I'm sure that books can be printed in your language without any need for semantic information in the characters.

How do you Ctrl+F in a printed book? Why printed when we're taking about digital?

Re: The Elegance of the ASCII Table

#170

Post by eviks »

> The first 32 “characters” (and, arguably, the final one) aren’t things that you can see, but commands sent between machines to provide additional instructions

Such a waste and no extensibility kills and claim to elegance of some shifted binary numbers, that'd the wrong end to focus your optimization efforts on

Post reply on HN