←back to thread

The provenance memory model for C

(gustedt.wordpress.com)
224 points HexDecOctBin | 8 comments | | HN request time: 0.841s | source | bottom
Show context
smcameron ◴[] No.44424882[source]
Ugh. Are unicode variable names allowed in C now? That's horrific.
replies(5): >>44424985 #>>44425020 #>>44425869 #>>44426140 #>>44426336 #
1. OkayPhysicist ◴[] No.44425869[source]
Why shouldn't they be? It's not the 00's anymore, Unicode support is universal. You'd have to dust off some truly ancient tech to find something incapable of rendering it.

Source code is for humans, and thus should be written in whatever way makes it easiest to read, write, and understand for humans. If your language doesn't map onto ASCII, then Unicode support improves that goal. If your code is meant to directly implement some physics formula, then using the appropriate unicode characters might make it easier to read (and thus spot transcription errors, something I find far too often in physics simulations).

replies(3): >>44425932 #>>44426021 #>>44426146 #
2. wheybags ◴[] No.44425932[source]
Hot take, but I've always felt the world would be better served if mathematicians and physicists would stop using terrible short variable names and use longCamelCaseDescriptiveNames like the rest of us, because paper is cheap, and abbreviations are confusing. I know it's nicer when you're writing by hand, but when you clean up a proof or formula for publishing, would it really be so hard to switch to descriptive names?

I'm a practitioner of neither though, so I can't condemn the practice wholeheartedly as an outsider, but it does make me groan.

replies(2): >>44426036 #>>44426288 #
3. someplaceguy ◴[] No.44426021[source]
> using the appropriate unicode characters might make it easier to read

It's probably also a great way to introduce almost undetectable security vulnerabilities by using Unicode characters that look similar to each other but in fact are different.

replies(1): >>44426189 #
4. senbrow ◴[] No.44426036[source]
Long names are good for short expressions, but they obfuscate complex ones because the identifiers visually crowd out the operators.

This can be especially difficult if the author is trying to map 1:1 to a complex algorithm in a white paper that uses domain-standard mathematical notation.

The alternative is to break the "full formula" into simpler expression chunks, but then naming those partial expression results descriptively can be even more challenging.

5. bigstrat2003 ◴[] No.44426146[source]
They shouldn't be precisely because it makes the code harder to read and write when you include non-ASCII characters.
6. OkayPhysicist ◴[] No.44426189[source]
This would cause your compilation to fail, unless you were deliberately declaring and using near identical symbols. Which would violate the whole "Code is meant to be easily read by humans" thing.
replies(1): >>44426222 #
7. someplaceguy ◴[] No.44426222{3}[source]
> unless you were deliberately declaring and using near identical symbols.

Yes, that would probably be one way to do it.

> Which would violate the whole "Code is meant to be easily read by humans" thing.

I'd think someone who's deliberately and sneakily introducing a security vulnerability would want it to be undetectable, rather than easily readable.

8. nsingh2 ◴[] No.44426288[source]
Better served to students and those unfamiliar with the field, but noisy to those familiar. Considering that much of mathematical work is done using pen/paper, it would be a total pain to write out huge variable names every time.

Consider a simple programming example, in C blocks are delimited by `{}`, why not use `block_begin` and `block_end`? Because it's noisy, and it doesn't take much to internalize the meaning of braces.