Why do programming languages use curly braces?
programmers.stackexchange.com
programmers.stackexchange.com
The OP is assuming the current US keyboard layout. C was developed on the PDP-11 which would likely have used a DECwriter II for the keyboard/output.
On that keyboard [ ] are on the same key (non-shift is [, shift is ]). Thus [ ] were not 'easier' on it. Similarly, { } were on the same key with non-shift being { and shift being }.
C's predecessor BCPL used { } although it was developed on a machine without a keyboard and so typing those characters was just as easy as any other character. The developer might have had access to an IBM card punch with a keyboard but the keyboards on those were odd (IBM layout) with no [] or {} and $( was used in place of {.
http://www.unicode.org/versions/Unicode6.1.0/ch07.pdf: "Another pair of characters, U+0133 latin small ligature ij and its uppercase version, was provided to support the digraph “ij” in Dutch, often termed a “ligature” in discussions of Dutch orthography. When adding intercharacter spacing for line justification, the “ij” is kept as a unit, and the space between the i and j does not increase. In titlecasing, both the i and the j are uppercased, as in the word “IJsselmeer.” Using a single code point might sim- plify software support for such features; however, because a vast amount of Dutch data is encoded without this digraph character, under most circumstances one will encounter an <i, j> sequence."
But don't take my word for it; I used Google to see what a Dutch keyboard layout is supposed to look like because I don't think I have ever seen one in real life.
There were typewriters with a ij ligature. That makes sense because that is about the worst kerning pair you can get in a monospaced font (but as a monospaced ligature, it is fairly tight with those large vertical stretches both at the left and at the right)
Switched to QWERTY, not looking back.
In order to type { }, I hit the shift key with my right pinkie finger, which shifts my entire hand over and allows me to hit the brackets with precision with my middle or ring finger. When I type [ ], I use my middle and ring fingers but without anchoring my hand to the right shift key, and I often hit the wrong character.
This is why I always found it awkward to program in Objective-C due to their extensive use of square brackets, whereas Java or PHP (or other C-like languages) come a lot more naturally (curly braces are more often used than square ones).
That was very common. The C compilers for the Atari 8 bit computers (which used the ASCII values for { and } for graphics characters) did this too.
* used { } instead of BEGIN and END keywords
* single type called WORD
* declared variables with LET
* used // style comments like C++
* used = instead of := for assignment
* variables could be declared AUTO or STATIC
* semicolons as statement terminators
* ++ and -- incrementors/decrementors in prefix and postfix position
* two types: int and char
* struct introduced in 1973
* /* */ style comments from PL/I
* && and || operators with short-cut semanticsdmr wrote at http://cm.bell-labs.com/cm/cs/who/dmr/bcpl.html that “C was invented in part to provide a plausible way of dealing with characters when one begins with a word-oriented language. [...] BCPL later found a solution better, on its own terms, by providing an operator (%) analogous to its !, such that v%i designates the i-th character in a vector. However, the earliest BCPL applications tended not to process packed characters in vectors, but to spread them out early into one character per word, process, and then pack them again if necessary.”
Algol and PL/I already offered what I consider proper arrays and string types.
The performance argument about bounds checking is stupid, because any proper compiler offered the possibility to disable bounds checking for code regions.
Sadly the decision taken was another one with the security consequences everyone was to endure with software written in C. At least C++ offers a way out for the developers that embrace STL and similar libraries.
Should we start to looking for a place to start this kind of discussion without lose the Q&A format? Reddit and HN might work but just a few of 'Ask HN' posts actually make the front page and, in my opinion, answers on Reddit don't have the same quality in comparison with SO.
Not a fan of this myself. When there is a pool of thousands of smart people who are willing to answer in a certain format, hundreds of thousands who are looking to read those answers in that format, outright banning that format is a little unfortunate in my opinion.
If you want to maintain a certain style for SO, then perhaps there's some outlet for these "discussion format" style questions on there that could be marked as such.
To disallow smart people from solving problems because they don't adhere to one strict format is a tragedy.
My question is: is there somewhere else where these kinds of questions (not totally on topic but still relevant to what programmers do) can be asked? I'd love to see more of them!
Then when you have the audience who were drawn in by the high signal focus on a topic of expertise, sucker punch them by closing down all such questions and cite some lame excuse of following the charter of purity. In the name of site quality they'll say.
"This is a collaboratively edited question and answer site for professional programmers interested in conceptual questions about software development."
http://programmers.stackexchange.com/questions/188455/why-do...
Very common on StackExcahnge. A bunch of high rep users swoop in and close questions that don't meet this weeks version of the rules that were decided in the Meta site that only the high rep users read. It reminds me a lot of Wikipedia.
You can see the process on a small scale with homeowner's associations.
(I put "manager" in quotes because there are good managers out there. Oddly, they're often the ones who are willing to break the rules when they don't make sense).
I wish more languages were like Python and didn't require so many cruft characters.
On the other hand, curly braces will plague you as long as you use C-inspired languages. An editor will only help you to more easily produce the cruft, it won't absolve you of the responsibility.
And once you learn to use curly braces, you don't forget that either. I haven't been plagued by curly braces since college - I work with C / C++ / Lua / Ruby on a daily basis. I seriously don't see how it's any different than remembering to indent your python code. An editor certainly doesn't absolve you of that responsibility either.
I'll put it this way - when I look at a block of code with braces (or begin / end), non-rendered characters don't affect the correctness of it.
Indention in non-Python code is 100% aesthetic; it doesn't affect program behavior, we just do it because it helps us non-compilers understand the code. And if you follow most any sane coding standard, indention will always be congruent with braces.
So, you're essentially attempting to convey the same concept -- program structure -- via 2 different mechanisms: tokens (curly braces) and indention, where of course the former is required, while the latter is the fodder of more flame wars than anyone cares to count. The sad thing is, these flame wars over code formatting are the most contentious to humans and yet the least meaningful to the compiler.
One solution would be to remove the indention -- hey, we already have the tokens informing us of the lexical code boundaries...but this produces unreadable code. The other solution is to remove the tokens; since we as humans will naturally structure our code in block paradigms, then we can piggyback on a behavior that is already innate to programmers.
However, this doesn't end up being really different from what Python does by rejecting mixed tabs and spaces. So.
And unlike languages with explicit begin/end markers, an editor can't re-format it or warn about it, because there is no information to work with.
Anyone who actually uses Python spends 0% CPU thinking about soft tabs because the editor is already set up to deal with this and almost everyone uses soft tabs, as suggested by PEP8.
Obviously if you're changing which statements are or are not part of a block and thus need to re-indent things per-line you'll need to do it manually, but you'd also need to manually move the braces around, and it'd be less obvious if you forgot.
HN needs /. style comment ratings for things like this. You deserve your "+1 funny" for that.
>curly braces will plague you as long as you use C-inspired languages
Curly braces don't cause (potentially hard to find) errors like mixed invisible indentation does. You can't be "plagued" by them at all, they are harmless. And they even let your code be completely unambiguous so you can use tools to reformat your code as you please/need.
Regarding your second point, curly braces do cause potentially hard-to-find errors, specifically when the indentation and the curly braces don't match up. Admittedly it's very easy to get into a set of habits where you don't do that, but the same can be said for the mixed indentation issue.
Also, Python is crufty by convention with its __init__ and __new__.
As for me, I've been using US International for a few years by now (because I use too many curly-braces languages and didn't want to give up being able to type ümläüts). But frankly, changing the keyboard layout just for a programming language is a bit evil. In that sense I liked BASIC and Pascal; I don't mind keywords instead of symbols that much either and I tend to be faster typing words anyway.
________
[1]: http://en.wikipedia.org/wiki/APL_(programming_language)
Anyways, if the keyboard layout is a blocking problem for you, consider changing it to what it suits you the best, or use multiple layouts for different tasks. Every operating system has a keystroke to swap layouts.
Those keys are really easy on US layout but horrible to type on a german keyboard layout. Holding alt-gr and press 7 or 8 or 9 or 0 is surely not impossible to type but compared to US layout it's much more worse, imo.
Fortunately Python does away with the overabundance of curly braces at least.
slightly worse I'll grant, but MUCH worse?
edit: Wow, just learned that Ctrl+Alt is the same as AltGr from the comment below. I've only used computers daily for 21 years ...
On a Danish Mac keyboard the curly braces are written by holding down Alt + Shift + 8. Not exactly an easy combination to hit.
> Most programmers often write their programs in english anyway
I'm not so sure about that. There are tons of places where English proficiency is really low, even among programmers.
When I first got the laptop I switched layouts between coding and writing mails, but after a while I found that learning the key combos for a few letters was easier for me than switching between completely different layouts.
myObject =
param1 : foo
param2 : bar
param3 : baz
foo bar,baz,boom
The alternative is `Polish (typewriter)' layout, with accented characters replacing most of punctuation, which doesn't seem to have caught on. Apparently entering accented characters with right Alt is comfy enough.
Surprisingly all that happened in spite of MS Windows default settings -- IIRC up to and including Windows 98, MS Windows defaulted to the legacy `Polish (typewriter)' layout, and only since Win XP (or perhaps 7) it defaults to the common `Polish (programmers)'.
At any rate, have a look at http://www.colemak.com/ which is quite programmer-friendly. I am using a variation of it.
Text is a good way to represent sequences of information. So it fits programs well, to some extent. But programs contains various kinds of information, that doesn't fit well with a textual representation: Hierarchical data, scope, branching flow, loops, dependencies, etc. These can be enhanced by a visual representational that goes beyond just text.
Besides the Visual representation, there is also the UI. Things like Vim for example, can be awesomely productive, in the hands of someone that has mastered it. But I would claim, that there is still space for improvement. With a visual interface, there are lots of things that can be done. Touch interfaces have lots of possibilities. Special inputs devices, would also be a great opportunity. But that would be harder, for obvious reasons. Maybe 3D printing would open opportunities there soon. The key for a visual UI to succeed, is to allow to do more with less effort.
Visual programming has not succeed so far. I would argue that it is because it has not been done right yet. I am currently working on these ideas, with one of my weekend's side projects. Since my time is limited, It is still going to take some time.
It's good to have an editor (like vi, following TECO) that takes advantage of the fact that this set of symbols is literally at the user's fingertips.
When I look at a complex Reaktor instrument (for instance Razor[1]), the entire paradigm seems to hit a wall at a certain point. The networks driving these instruments are an intricate mess and their visual representation can actually make it harder to grasp them in their entirety.
[1] http://www.native-instruments.com/en/products/komplete/synth...
is much easier then this: https://en.wikipedia.org/wiki/File:German-Keyboard-Layout-T2...
Of course that's probably the reason why the braces were chosen at all :P
It can't be because physical keyboards wouldn't have the key, because my keyboard doesn't display a # symbol, but that is widely used.
I can only guess that the character sets and "what characters are easy to type into a computer" became standardised early on, and no individual language has been able to push such a change (Early in development a language has few users, thus no influence; Later in development, the language has been using "->" itself for a while, so it's less easy to change).
Also, proper languages like lisp use parentheses (), not curly braces. :p
Relatively large-scale production required I/O devices to share a common character set. These tended to be based on pre-computer character sets (teletypes, punched cards) and were limited in size both by the I/O devices and by storage requirements (don't forget how small and expensive memories were). A lot of work went into choosing character sets.²³⁴
1963 ASCII had an up arrow ‘↑’ dropped in 1967 in favour of ^ (because furriners wanted accents), and a left arrow ‘←’ dropped in favour of ‘_’.⁵⁶
¹Jean Sammet, Programming Languages: History and Fundamentals 978-0137299881 ²Charles E. MacKenzie, Coded Character Sets: History and Development 978-0201144604 ³http://www.trailing-edge.com/~bobbemer/SURVEY.HTM ⁴R W Bemer, Design of an improved transmission/data processing code http://dx.doi.org/10.1145/366532.366538 ⁵American Standard Code for Information Interchange http://www.wps.com/projects/codes/X3.4-1963/index.html ⁶Revised U.S.A. Standard Code for Information Interchange http://www.wps.com/J/codes/Revised-ASCII/index.html
Languages which support this (including Agda, I believe) usually support some fallback to ASCII, allowing you to type "->" instead of a Unicode arrow, because it's easier to type on the vast majority of keyboards.
Of course, APL also famously uses all kinds of symbolic nonsense.
For example: https://github.com/ehamberg/vim-cute-python
Is that serious language then? We learned that back at University when I was doing my CS degree. Other students were scathing about it, going on about why we weren't doing C. But it was used as a simple introduction to programming techniques to prepare for C, Java etc. I understood its value back then as an introduction, but I never realise it had a use beyond that. I have to say, I quite enjoyed using it, and I was a little disappointed to move way from it to "proper" languages at the time.
So, it is used in anger, as it were, now? If so, what can it be used for? Part of me would love to pick it up again for something vaguely serious.
The Lillith operating system was written in it. A fully working operating system with what could be considered a kind of GUI environment on those days.
It was used at Zurich's university and a few others around the world.
You can have a look at it here:
http://www.youtube.com/watch?v=ob0lznzkykc (Lilith Comdex Demo) http://weblog.hansotten.com/?p=490 (Emulator) http://www.modulaware.com/mdlt52.htm (Some background history)
There were a few companies selling commercial Modula-2 compilers like Garden's Point and Excelsior. There was a UNIX system that had it as part of their compiler suite, I cannot remember which one now.
It failed to fully replace Pascal, because eventually Mac/Turbo Pascal came along and most Pascal compilers had extensions that made them compatible with Mac/Turbo Pascal. Since those Pascal extensions were similar to what Modula-2 offered and many companies already had an investment in Pascal code, many kept using Pascal instead of moving into Modula-2.
When UNIX gained much of the space in the enterprise world, C was the language to use if you didn't want to justify why you were using something else, so that was like the final nail in Modula-2's coffin.
It is very hard for a systems programming language to gain market share if it isn't the official language used by the operating system's vendor.
The language is quite powerful, when compared with C, with the added benefit of proper modules, strings and arrays. Not the pointer everywhere from C which leads to security exploits by design, so to speak.
Its time has passed, now a proper replacement would be something like Oberon, when looking at Wirth's family of languages. You can use it to program embedded systems, http://www.astrobe.com/default.htm.
--Edit: No, seriously, why not? There are only a few different opening-closing character pairs on a keyboard: [], (), <>, {}, /\, etc. It's not that different to type any of them.
So why is this even a question? It's because we used the others up and that was next on the list, and it looks somewhat logical as a container of things. So again, wholly and completely, the answer is in the question: "why not?"
My 3 groats here says lots.
[] are used for indexing, which is probably used more. So regardless of the historical reason, it makes sense to use something visually distinct for blocks.