3 ms·

The underscore in computing was developed to be able to separate words used as part of a variable name on computers with only upper-case. Quoting https://en.wik

by dalke 11y ago

The underscore in computing was developed to be able to separate words used as part of a variable name on computers with only upper-case. Quoting https://en.wikipedia.org/wiki/Underscore#History https://en.wikipedia.org/wiki/Underscore#History : > IBM's report on NPL (the early name of what is now called PL/I) leaves the character set undefined, but specifically mentions the break character, and gives RATE_OF_PAY as an example identifier It links to the 1964 report at http://bitsavers.informatik.uni-stuttgart.de/pdf/ibm/npl/320-0908_NPL_Technical_Report_Dec64.pdf http://bitsavers.informatik.uni-stuttgart.de/pdf/ibm/npl/320... which defines the "_" as the "break" character, on page 22, and on p23 says "[A]n identifier is a string of alphabetic characters, igis, and break characters with the initial character always alphabetic. Any number of break characters are allowed within an identifier; however, consecutive break characters are not permitted. Also, a break character cannot be the final character of an identifier." (To verify the timing, "_" was not in X3.4 1963 (see http://worldpowersystems.com/archives/codes/X3.4-1963/page6.JPG http://worldpowersystems.com/archives/codes/X3.4-1963/page6.... ) and that ASCII code point was instead "left arrow".) You argument regarding "more files to be viewed on a single screen" is valid, but incomplete. It's more a question of total program comprehension rather than a single metric. This is hard to measure. We can look to related metrics of speed-of-identification and accuracy to see how messy the subject is. The report at http://www.cs.kent.edu/~jmaletic/papers/ICPC2010-CamelCaseUnderScoreClouds.pdf http://www.cs.kent.edu/~jmaletic/papers/ICPC2010-CamelCaseUn... says that programmers who are trained in underscore style can recognize underscore style more quickly than camel case, while https://www.researchgate.net/publication/221219628_To_camelcase_or_under-score https://www.researchgate.net/publication/221219628_To_camelc... says that camel case is all around better. At the very least it suggests that "most practical style" is hard to determine.

EvanPlaice 11y ago
Meta characters were also added for file, unit, record, and group separators. Some may correctly argue that using these chars to structure data in flat files is a more simple and technically superior solution to the alternatives. Still, people will stick to what they're familiar with despite the technical benefits. That's why we have CSV, TSV, JSON, etc. I'd argue that 'most practical' is whatever format most people immediately understand at first glance. That literally means everybody, not just a small subset of programmers who already use a perticular sytling standard.
- dalke 11y ago
  "whatever format most people immediately understand at first glance" Certainly that's a useful starting point. The problem is in figuring that out when there are multiple, roughly similar representation. But it also depends on the goal. Sometimes it's better to learn a new format (Einstein notation, bra-ket notation, copy editing and proofreading symbols, modern staff notation for music, shorthand, etc.) than to use a system that a larger subset of people will understand immediately. Forth is an example of a programming language which is developed for programmer productivity, on the assumption that the programmer will put in the effort to be proficient in the language.
  - EvanPlaice 11y ago
    I was speaking in terms of the 'eventual' case, not a starting point. While optimizing syntax/form makes sense in highly specialized domains where no useful alternative exists, I'd argue that the opposite holds true in domains where more 'natural' alternatives are abundant. Can't say I'm familiar with all of those. For proofreading, meta chars are necessary to indicate edits without the ability to mutate the original text. Musical notation has widely been replaced by tabs for guitar. Shorthand may be useful for writing that isn't consumed by others. Cursive is a perfect example of a form of language that was created for efficiency. Which, arguably, held true for handwriting. But it didn't add enough of a benefit above/beyond plain handwritten text and was very difficult to duplicate digitally. Not to rag on Fourth, I'm sure it's probably a very good language but how widely is it used today? Like I said, no amount of research proving that programmers choose languages based purely on their technical merits can disprove the writing on the wall. People choose what feels natural to them based on previous experience and/or common convention. Whatever choice requires the least amount of context switching overhead and allows the lowest barrier of communication between devs will win in the end. That's why Typescript is immensely popular for developers with a strong OOP background that prefer writing code in an IDE. For C, the low level support for types and memory access make it a natural fit for systems development. I have written low level network code in C#, it's an extremely awkward and verbose mess. Python wins when it comes to simplicity and the ability to write really powerful functionality with a minimum amount of code. The list slicing as well as comprehensions are easy to understand and increase productivity dramatically.

by dalke 11y ago

EvanPlaice 11y ago

Meta characters were also added for file, unit, record, and group separators. Some may correctly argue that using these chars to structure data in flat files is a more simple and technically superior solution to the alternatives. Still, people will stick to what they're familiar with despite the technical benefits. That's why we have CSV, TSV, JSON, etc. I'd argue that 'most practical' is whatever format most people immediately understand at first glance. That literally means everybody, not just a small subset of programmers who already use a perticular sytling standard.

dalke 11y ago
"whatever format most people immediately understand at first glance" Certainly that's a useful starting point. The problem is in figuring that out when there are multiple, roughly similar representation. But it also depends on the goal. Sometimes it's better to learn a new format (Einstein notation, bra-ket notation, copy editing and proofreading symbols, modern staff notation for music, shorthand, etc.) than to use a system that a larger subset of people will understand immediately. Forth is an example of a programming language which is developed for programmer productivity, on the assumption that the programmer will put in the effort to be proficient in the language.
- EvanPlaice 11y ago
  I was speaking in terms of the 'eventual' case, not a starting point. While optimizing syntax/form makes sense in highly specialized domains where no useful alternative exists, I'd argue that the opposite holds true in domains where more 'natural' alternatives are abundant. Can't say I'm familiar with all of those. For proofreading, meta chars are necessary to indicate edits without the ability to mutate the original text. Musical notation has widely been replaced by tabs for guitar. Shorthand may be useful for writing that isn't consumed by others. Cursive is a perfect example of a form of language that was created for efficiency. Which, arguably, held true for handwriting. But it didn't add enough of a benefit above/beyond plain handwritten text and was very difficult to duplicate digitally. Not to rag on Fourth, I'm sure it's probably a very good language but how widely is it used today? Like I said, no amount of research proving that programmers choose languages based purely on their technical merits can disprove the writing on the wall. People choose what feels natural to them based on previous experience and/or common convention. Whatever choice requires the least amount of context switching overhead and allows the lowest barrier of communication between devs will win in the end. That's why Typescript is immensely popular for developers with a strong OOP background that prefer writing code in an IDE. For C, the low level support for types and memory access make it a natural fit for systems development. I have written low level network code in C#, it's an extremely awkward and verbose mess. Python wins when it comes to simplicity and the ability to write really powerful functionality with a minimum amount of code. The list slicing as well as comprehensions are easy to understand and increase productivity dramatically.