In the words of my combinatorics professor, Dave Bayer:
> It is hard to shed prejudices about how code should look, even if learning to see clearly past convention is the only good reason to be a mathematician. I'm already quite sure how I will die: I'll read another article on Hacker News about a new programming language where I see nothing new, and I'll read that they included {}; to make C programmers comfortable. I'll have a massive stroke.
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 closer to its use, because variables can only be defined at the start of its block (although that no longer applies in C99). Conversely, though it's usually bad practice, you can use if statements and loops with individual statements.
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. < and > 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.
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.
I remember reading Unix source in Geoff Steckel‘s office at Harvard who got the first Unix distribution outside of their labs and the line printer would just would use overstrike on parentheses to designate curly braces and upper case (lower case was printed as upper since the line printer didn’t have lower).
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" and <these> were called "angle brackets" in the 1970s, but when did anyone in the computer industry ever start calling anything but {these} braces?
> 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).
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” 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.”
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 Pascal used ( and ) instead of [ ] for arrays because neither brackets nor braces could be typed.
To summarize from the article for { and }:
Modern digraphs:
<% , %>. This is only one that looks symmetric
Less-modern trigraphs:
??< , ??>
Unix v4 (in the teletype driver):
\( , \)
PDP-11 B:
*( , *)
PDP-7 B:
$( , $)
In other micro software (Advanced MuMath for the TRS-80), I have seen:
<< , >> for [ , ]
(< , >) for { , }
Back in the 80's, the joke among new learners of C and Unix is that the designers must have had a very bad keyboard where typing each character was painful, because every keyword or command was so short and cryptic. This article suggests a different reason: on their 36-bit Honeywell 6070, "four characters fit into a word", so there was incentive to fit in 1 machine word.
It also explains why they used the obscure characters {,},|, and ~ while never using the FAR more common # and @. In the Teletype driver, "#" is clear previous char, and "@" is clear current line. So unavailable for C. 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! On every keyboard! So now every newbie to C has to stop thinking "multiplication" when they see *.
> 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.
"In addition to missing lowercase, ASCII 1963 and the Model 33 lacked { } curly braces, | vertical bar, ` backtick, and ~ tilde, and they had ↑ up arrow instead of ^ caret and ← left arrow instead of _ underscore."
explains why Smalltalk used the up arrow and left arrow for fairly reasonable punctuation for return and assignment.
Up arrow was replaced much later by caret and left arrow was sadly replaced by :=
Some BCPL dialects/implementations used underscore instead of := for assignment. MUD 1 was written in such a dialect, see e.g. [0]; also, note that it allowed the use of "." in identifiers.
Left arrow was replaced by _, which (in Squeak anyway) is actually an assignment operator, with := as an alias.
Some computers going into the 80s, for example the Commodore 8-bit line starting with the PET and going through the Commodore 128, still had ↑ and ← for ^ and _.
Interesting. I do not remember exactly what system or language I used in collage, but for some reason I thought a { and } was encoded as [[ and ]] or some kind of double character like that. I new Fortran at the time, but that other language needed '{}'.
In the words of my combinatorics professor, Dave Bayer:
> It is hard to shed prejudices about how code should look, even if learning to see clearly past convention is the only good reason to be a mathematician. I'm already quite sure how I will die: I'll read another article on Hacker News about a new programming language where I see nothing new, and I'll read that they included {}; to make C programmers comfortable. I'll have a massive stroke.
{} 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 closer to its use, because variables can only be defined at the start of its block (although that no longer applies in C99). Conversely, though it's usually bad practice, you can use if statements and loops with individual statements.
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. < and > 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.
That's like saying we could use a totally different set of runes than our alphabet.
Yes, but why?
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.
I don’t think there’s any branching in intitializer lists or declarations.
Don’t forget when they’re in string literals?
I remember reading Unix source in Geoff Steckel‘s office at Harvard who got the first Unix distribution outside of their labs and the line printer would just would use overstrike on parentheses to designate curly braces and upper case (lower case was printed as upper since the line printer didn’t have lower).
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" and <these> were called "angle brackets" in the 1970s, but when did anyone in the computer industry ever start calling anything but {these} braces?
> 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).
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” 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.”
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 Pascal used ( and ) instead of [ ] for arrays because neither brackets nor braces could be typed.
To summarize from the article for { and }:
Modern digraphs:
Less-modern trigraphs: Unix v4 (in the teletype driver): PDP-11 B: PDP-7 B: In other micro software (Advanced MuMath for the TRS-80), I have seen: Back in the 80's, the joke among new learners of C and Unix is that the designers must have had a very bad keyboard where typing each character was painful, because every keyword or command was so short and cryptic. This article suggests a different reason: on their 36-bit Honeywell 6070, "four characters fit into a word", so there was incentive to fit in 1 machine word.It also explains why they used the obscure characters {,},|, and ~ while never using the FAR more common # and @. In the Teletype driver, "#" is clear previous char, and "@" is clear current line. So unavailable for C. 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! On every keyboard! So now every newbie to C has to stop thinking "multiplication" when they see *.
> 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.
"In addition to missing lowercase, ASCII 1963 and the Model 33 lacked { } curly braces, | vertical bar, ` backtick, and ~ tilde, and they had ↑ up arrow instead of ^ caret and ← left arrow instead of _ underscore."
explains why Smalltalk used the up arrow and left arrow for fairly reasonable punctuation for return and assignment.
Up arrow was replaced much later by caret and left arrow was sadly replaced by :=
Some BCPL dialects/implementations used underscore instead of := for assignment. MUD 1 was written in such a dialect, see e.g. [0]; also, note that it allowed the use of "." in identifiers.
[0] https://github.com/PDP-10/MUD1/blob/master/MUD3.BCL#L96
hang about, the smalltalk return operator is why objc block syntax uses carets, isn't it? how did that only just click for me?
Hard to tell from a short comment, and maybe you already know, but a lot of obj-c is derived from smalltalk.
Left arrow was replaced by _, which (in Squeak anyway) is actually an assignment operator, with := as an alias.
Some computers going into the 80s, for example the Commodore 8-bit line starting with the PET and going through the Commodore 128, still had ↑ and ← for ^ and _.
Interesting. I do not remember exactly what system or language I used in collage, but for some reason I thought a { and } was encoded as [[ and ]] or some kind of double character like that. I new Fortran at the time, but that other language needed '{}'.
You're likely thinking of trigraphs - alternatives to some characters: https://stackoverflow.com/questions/1234582/purpose-of-trigr...
[dead]