Curly braces: An evolution of Unix and C • Hacker News Board

Re: Curly braces: An evolution of Unix and C

#21

Post by smcameron » Mon, May 25, 2026, 4:51 AM UTC

hyperhello wrote: post #16

quietbritishjim wrote: post #15

Earlier quoted context omitted.

You can use a different pair of symbols (or pair of words, like in Pascal, or whitespace, like in Python). There's certainly nothing fundamental about them. Also, even in C and C++, they don't indicate branching. You can place a brace block anywhere you can place a normal statement. You might use them in C++ just to delimit the extent of a RAII object. In C89 you might use a block to delay defining a variable until c…

I know it’s arbitrary and I know the symbol has been overloaded since they ran out of them, but at one time there was a certain economy and simplicity. meant less than and greater than; { } were code blocks; even the semicolon was the right thing to use to break statements. I wish they had stuck to that kind of readability because I don’t know what C++ thinks it’s doing anymore.

> I don’t know what C++ thinks it’s doing anymore.

C++, when increment becomes excrement, decrement back to C.

Re: Curly braces: An evolution of Unix and C

#22

Post by hyperhello » Mon, May 25, 2026, 5:46 AM UTC

fanf2 wrote: post #18

hyperhello wrote: post #11

Earlier quoted context omitted.

{} are important signals that code can and will branch at those points. They’re fundamental to reading.

I don’t think there’s any branching in intitializer lists or declarations.

Don’t forget when they’re in string literals?

Re: Curly braces: An evolution of Unix and C

#23

Post by xigoi » Mon, May 25, 2026, 7:19 AM UTC

jrdres wrote: post #13

Interesting. In the 70's & 80's, 8-bit microcomputers had a the same problem as old teletypes: you couldn't type in some ASCII characters even when the computer could display them. (And many couldn't.) At least some home-grown tiny-C compilers allowed a Pascal-like "BEGIN" and "END" substitute, which I'm sure would be an abomination to Kernighan. Even Pascal itself could have a problem: the very popular TRS-80 Tiny P…

> I will still curse the C designers to my dying day for picking * as the prefix operator for dereference pointer, when the more logical @ character was SITTING RIGHT THERE!

And what’s worse, many other languages copied this decision without understanding why it was made and why it’s completely nonsensical for modern languages.

Re: Curly braces: An evolution of Unix and C

#24

Post by digitalPhonix » Mon, May 25, 2026, 7:37 AM UTC

wlindley wrote: post #17

Isn't it odd to read "curly" braces? Every printed dictionary I have, up through the 1990s at least, says that braces are {these}, brackets are [these], and parentheses are (these). Saying "curly brace" is as redundant as saying "round parentheses." Yes, braces are curly, by definition. At least that's how it always in American English, and ASCII. Apparently British English says more than [these] can be "brackets" an…

> At least that's how it always in American English

You already found the answer.

To me, all of ()[]{} (and depending on context ) are “brackets” in the sense that they bracket whatever is between them. Then a brace is a single side of a bracket (ie. opening brace plus closing brace make a bracket).

So to distinguish between the different brackets/braces you use “round”, “square”, “curly” or “angled” respectively. And “round” is the default so you often skip specifying that.

That’s been the convention in programming and maths everywhere I’ve worked outside America (in English).

Re: Curly braces: An evolution of Unix and C

#25

Post by piekvorst » Mon, May 25, 2026, 10:51 AM UTC

wlindley wrote: post #17

Isn't it odd to read "curly" braces? Every printed dictionary I have, up through the 1990s at least, says that braces are {these}, brackets are [these], and parentheses are (these). Saying "curly brace" is as redundant as saying "round parentheses." Yes, braces are curly, by definition. At least that's how it always in American English, and ASCII. Apparently British English says more than [these] can be "brackets" an…

“Curly braces” reads like “the braces—curly ones.” Pointedly emphatic when you want to stress a particular aspect of a thing, much like “rational animals” instead of “humans.”

Re: Curly braces: An evolution of Unix and C

#26

Post by fluffybucktsnek » Mon, May 25, 2026, 6:21 PM UTC

quietbritishjim wrote: post #15

hyperhello wrote: post #11

Earlier quoted context omitted.

{} are important signals that code can and will branch at those points. They’re fundamental to reading.

You can use a different pair of symbols (or pair of words, like in Pascal, or whitespace, like in Python). There's certainly nothing fundamental about them. Also, even in C and C++, they don't indicate branching. You can place a brace block anywhere you can place a normal statement. You might use them in C++ just to delimit the extent of a RAII object. In C89 you might use a block to delay defining a variable until c…

A pair of words requires more keywords (they also tend to be more verbose) and whitespace has ergonomy issues (specially with copy-pasting). Whitespace may come with intrinsic alignment, but formatting tools do short work of that.

Re: Curly braces: An evolution of Unix and C

#27

Post by Pinus » Tue, May 26, 2026, 4:37 AM UTC

Did anyone ever actually use trigraphs or digraphs in C? All I ever saw in Sweden (where the most commonly used seven-bit character encoding lacked brackets, braces, backslash and vertical bar) was to just use the same code points and writing int main(int argc, char argvÄÅ) ä ... å, or setting your terminal to use USASCII, l|{v}ng your pl{}n t|xt look}ng l}k| th}s.

Re: Curly braces: An evolution of Unix and C

#28

Post by 1718627440 » Tue, May 26, 2026, 1:03 PM UTC

7bees wrote: post #19

wlindley wrote: post #17

Isn't it odd to read "curly" braces? Every printed dictionary I have, up through the 1990s at least, says that braces are {these}, brackets are [these], and parentheses are (these). Saying "curly brace" is as redundant as saying "round parentheses." Yes, braces are curly, by definition. At least that's how it always in American English, and ASCII. Apparently British English says more than [these] can be "brackets" an…

Curly braces are a very uncommon piece of punctuation outside of math and programming. If you picked a person at random, they will find "curly brace" (and indeed, "square bracket") much clearer and less ambiguous. Doubly so when accounting for variations between British and American English.

Curly braces are a very uncommon piece of punctuation outside of math and programming.

They are used, but they do not occur in linear text, but as a way to group multiple lines or in an ornamental/page structuring way.

Re: Curly braces: An evolution of Unix and C

#29

Post by apple4ever » Tue, May 26, 2026, 10:35 PM UTC

xigoi wrote: post #23

jrdres wrote: post #13

Interesting. In the 70's & 80's, 8-bit microcomputers had a the same problem as old teletypes: you couldn't type in some ASCII characters even when the computer could display them. (And many couldn't.) At least some home-grown tiny-C compilers allowed a Pascal-like "BEGIN" and "END" substitute, which I'm sure would be an abomination to Kernighan. Even Pascal itself could have a problem: the very popular TRS-80 Tiny P…

> I will still curse the C designers to my dying day for picking * as the prefix operator for dereference pointer, when the more logical @ character was SITTING RIGHT THERE! And what’s worse, many other languages copied this decision without understanding why it was made and why it’s completely nonsensical for modern languages.

Objective-C for the win!!

(They use @ for marking keywords)