Why do programming languages use curly braces?(programmers.stackexchange.com)
programmers.stackexchange.com
Why do programming languages use curly braces?
http://programmers.stackexchange.com/q/188455/54164
92 comments
On German (and I think also Dutch) keyboards, {} are on AltGr-7 and 0, which is a pain to type (and the reason why I switch every computer to US keyboard). I wonder if that's why Python uses indentation and not braces for blocks...
Dutch people use US International layout keyboards almost exclusively (@ above 2). The Dutch layout (# above 2) is very very rare.
Out of interest how do dutch keyboards handle the IJ
Typically: not. Historically, I don't think there were character sets that had it as a character. Unicode nowadays has it, but discourages its use.
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)
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)
Flemish (Belgian Dutch) keyboards have them at AltGr9 and AltGr0. Works just fine, if you ask me.
I'm also a Fleming and I HATE our keyboard. For example languages with $ signs for variables are horrible with it. $ needs AltGr and is all the way to the right. Thus requiring you to leave the home row completely. (Not even getting into how moronic the placements of (){}[] are.)
Switched to QWERTY, not looking back.
Switched to QWERTY, not looking back.
Ah, nog ne Howest-er :p
As far as I can tell, after having read Martin Richards's BCPL book and the BCPL reference manual, BCPL allowed only $( $) as section brackets. Looking at the current BCPL compiler code, it seems that it does now allow { } for section brackets, but the comments in the compiler suggest that it wasn't added until 1995. BCPL's section brackets were neat in that you could add a label to them and they would be parsed much like HTML tags. I think it's likely that B introduced the curly brackets in lieu of BCPL-style section brackets and omitted tagged brackets altogether, then B begat C, etc.
My preference on an American keyboard is still curly braces, probably because of my typing style.
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).
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).
"$( was used in place of {."
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.
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.
Features of BCPL (Martin Richards, 1967):
* 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 semanticsSadly proper arrays and strings were left somehow along the way.
BCPL vectors seem to be the same as C arrays, no?
dmr 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.”
dmr 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.”
I meant about the design decision to ignore what other system programming languages were already offering on those days.
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.
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.
[Slightly off topic]
It's just me or now a lot of very interesting threads in SO are being closed as "not constructive"
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.
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.
Simple answer: http://meta.stackoverflow.com/questions/110350/why-are-usefu...
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.
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.
They already split off "programmers" from the main StackOverflow site to address this exact issue, and history is repeating itself. Now it seems we need individual sites for programmers-offtopic, programmers-trivia, programmers-history. Make those, and as time goes by, each one will be moderated more and more heavily until they form their own spinoffs.
It's spin offs all the way down.
This is very much a side comment, but I've noticed that there are a lot of these kinds of questions on StackExchange, but it seems like a lot of them are closed (this one was closed within an hour of it being opened) because they don't fit within the goals of StackExchange.
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!
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!
You'll have to create an audience draw for it as well. Say, promise them the site won't be overrun by endless discussions about which Aeron chair is the best to sit on a treadmill.
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.
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.
http://programmers.stackexchange.com/
"This is a collaboratively edited question and answer site for professional programmers interested in conceptual questions about software development."
"This is a collaboratively edited question and answer site for professional programmers interested in conceptual questions about software development."
You would think, but the same question was closed there as Not Constructive:
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.
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.
It reminds me a lot of any human organization that develops a "manager" class. There are a lot of people whose goals in life have more to do with controlling what other people do and making sure that the rules are followed, rather than contributing actual work.
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).
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 really like the /r/learnprogramming subreddit -- You can ask anything relevant to programming and you'll get earnest answers with minimal trolling (the mods do a great job there).
Yes, there is a place. Usenet is a popular forum for holy wars about the lexical syntax of various programming languages.
Tokens of a bygone era.
I wish more languages were like Python and didn't require so many cruft characters.
I wish more languages were like Python and didn't require so many cruft characters.
The first time I ran into the spaces vs. tab problem I wanted my curly braces back.
That's an issue you run into once, set your editor, and then never have to worry about it again.
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.
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.
You run into it again when you start working with other developer's code.
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.
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.
I just think they're redundant.
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.
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.
I agree with you. It seems odd that we have the structural information in our program twice: Once for humans, and once for computers. The computers are perfectly capable of understanding the human construct, so let's use that.
Enforcing a convention (like go fmt) will also take care of the issue.
However, this doesn't end up being really different from what Python does by rejecting mixed tabs and spaces. So.
However, this doesn't end up being really different from what Python does by rejecting mixed tabs and spaces. So.
Until you refactor some python code and the indentation gets messed up without you noticing... Been there, done that.
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.
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.
Perhaps you didn't understand, but that doesn't happen when you set up your editor.
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.
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.
There's no reason an editor can't reformat most cases. If you copy a block of text out of one indentation-level and into another, you simply need to adjust the leading indents by a fixed amount.
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.
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.
Technically, you don't have to type any { or } to write C code. ??< and ??> will do 'fine' as replacements, as do <% and %> (http://en.wikipedia.org/wiki/Digraphs_and_trigraphs#C)
>That's an issue you run into once, set your editor, and then never have to worry about it again.
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.
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.
[deleted]
Much as I like the /. "semantic rating" system, I'm glad HN doesn't have it, so we don't get these sorts of passive-aggressive ratings.
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.
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.
Except that there is no potential for ambiguity, so tools can easily highlight indentation that doesn't match braces as an error for you, and tools like "indent" can automatically indent the code correctly based on the braces.
But those are both ways to keep your two different notations for structure in sync. If you only have one structure, you don't have that problem in the first place.
Invisible cruft! The worst.
Also, Python is crufty by convention with its __init__ and __new__.
Also, Python is crufty by convention with its __init__ and __new__.
Or lisps. Commas in sequences? Cruft!
I always wonder why so many languages are sooo bad to use on a non-us keyboard.. I'd love if language designers would consider other keyboard layouts more often.. :(
The APL [1] designers heard you and created a language impossible to type on almost every keyboard layout [2] ;-)
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)
[2]: http://en.wikipedia.org/wiki/File:APL-keybd2.svg
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)
[2]: http://en.wikipedia.org/wiki/File:APL-keybd2.svg
This made me search to see if there was any 256 key keyboards so I could have a key for every byte, but I apparently no one has been that crazy yet.
I like many parts of Unicode ∖ Latin-1. 256 keys might not be enough ;-)
You'll just have to learn to do one of the encodings in your head.
Most programmers often write their programs in english anyway, to be easy to share or to review by others (even in closed source software), so it makes sense for programming languages to mostly care about English keyboard layouts.
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.
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.
It's not about writing english per se.
How often do you need to write {[]}<> in a letter?
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.
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.
Why is Alt+9/0 so much worse than Shift+[/]
slightly worse I'll grant, but MUCH worse?
slightly worse I'll grant, but MUCH worse?
It's AltGr, which is on the right side. And that makes it quite awkward to use. I either break half my hand or need both hands. Or resort to Ctrl+Alt on the left side which isn't optimal either ...
Wow.. now i'm wondering how quickly (if ever) i can adopt to using ctrl+alt instead of that awkward (and hated) AltGr.
You never stop learning...
Couldn't you remap your keys so normal (left) Alt is AltGr and right Alt is "normal" Alt? Alt key bindings are pretty rare.
They are? Every time I want to access a menu or a control in a dialog by keyboard I need Alt. Also in Far Alt+typing searches which I use frequently to get around the file system. Sure, one could get used to doing that with the other hand, but at least for me it's not that little muscle memory that has to be retrained.
It's AltGr+7/0 though (on german and swedish layouts at least), which is much worse. Open curly brace is a killer if you are doing it with one hand only. Also the AltGr button is only represented on the right side of the keyboard while you get the Shift on both sides, which makes it more awkward to use with two hands in some situations.
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 ...
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 ...
Slightly times a lifetime.
I write software in English, sure, but my keyboard layout needs to be Danish in order for me to write emails, etc. in Danish. Having to swap keyboard layouts would mean I'd be confused constantly.
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.
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.
I write norwegian on a US MacBook just fine. All the weird characters are available by pressing the Option key.
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.
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.
it is one thing write programs in english , i have a french keyboard , typing english is fine , the problem is all the non word stuff that are not directly visible on my keyboard like {}[]|\] and so on. You kind of get used to it but frankly i dream of a language with non of these characters, just words. typing def/end doesnt bother me. By the way , that's kind of why i love coffee-script so much.
myObject =
param1 : foo
param2 : bar
param3 : baz
foo bar,baz,boom
In Poland, the most common layout is the `Polish (programmers)', virtually the same as US layout, with extra right Alt switching for polish accented characters.
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.
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.
There is also the possibility of ditching entirely the approach of text based programming, for a more visual approach. This will not work for many people, but for those that it does work, it could improve productivity.
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.
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.
I'm not convinced it can be done right, because alphabets are inherently superior to ideograms. Making a small set of symbols capable of representing language is one of humanity's greatest inventions.
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.
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.
Thanks for the answers. I am interested in hearing feedback. This is a very interesting topic for me.
There are a lot of visual programming environments that are used in the creative industries, environments such as MAX/MSP, Pure Data, Houdini (CGI / FX) or NI Reaktor...
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...
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...
FWIW, braces (and brackets and parentheses) aren't all that pleasant to type on a US keyboard either.
This: https://en.wikipedia.org/wiki/File:KB_US-International.svg
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
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
There's dedicated keys for brackets and parentheses in relatively easy-to-reach positions. How could you make that more pleasant?
I realized I probably write more curly braces than accented characters during the day and switched to using an US-International style keyboard layout that puts the diacritic characters under the Alt Gr key.
Treat keyboard layouts as a part of your software tool set. If the one the OS gave you doesn't work well (and they are universally pretty bad), find or build one that does.
I sometimes wonder why languages use sequences like "->". This is clearly meant to represent an arrow, so why has noone ever taken the time to make sure an arrow character is defined, make sure it's possible to type it in most keyboard maps and use it in programming languages.
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
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
Several early programming systems did use custom character sets (custom type bars) as well as typewriter-oriented notations like overstrikes, half-line motions for superscripts (powers) and subscripts (indexes), and colour (red half of the ribbon for comments)¹. Except for APL, which had IBM behind it, these tended not to escape their original research environments.
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
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
Some languages do support Unicode for things like arrows and other mathematical symbols: http://wiki.portal.chalmers.se/agda/pmwiki.php?n=ReferenceMa...
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.
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.
Not entirely the same thing, but there are some plugins for Vim, Emacs,... that show different figures/characters in place of things like "=>" or "lambda". But don't actually change your source code.
For example: https://github.com/ehamberg/vim-cute-python
For example: https://github.com/ehamberg/vim-cute-python
A meta comment: It's pretty awesome that we're already having lore discussions about our craft 50 years later. I wonder what they'll be discussing in a 100 years about our languages now and why certain decisions were made.
We will discussing how it was possible that C could endure for so many years delaying the use of safer languages for systems programming along the line of Modula-2 and Ada.
Modula-2 ????????
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.
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.
It used to be a serious language back in the day (up to early 90's).
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.
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.
Well... why not?
--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?"
--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?"
Because on non-English keyboards curly braces are a pain to type. E.g. in Danish it requires Alt + Shift + 8 (on a Mac), and if you look at the comments above you'll see that the problem is the same for many other languages.
I wonder what percentage of questions with the highest hit rate on SO and SE have "closed as not constructive by x" on them.
My 3 groats here says lots.
My 3 groats here says lots.
> and why not something more reasonable, like [], which doesn't require the shift key at least on US keyboards
[] 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.
[] 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.
Smalltalk uses [] for blocks, and somehow it just looks jagged and unpleasant to read, to me: [[[]]] doesn't nest nicely like ((())) or {{{}}}. I don't propose this as an explanation of anything; but I'm glad it isn't [].
[deleted]
[deleted]
The "what question is interesting enough to reach HN front page so we can close it" watch is alert and active, thank you
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 {.