5 ms·

Yeah, try explaining “drive C:” to a kid these days, and why it isn’t A: or B: … Of course software developers are still stuck with 80 column conventions even

Yeah, try explaining “drive C:” to a kid these days, and why it isn’t A: or B: … Of course software developers are still stuck with 80 column conventions even though we have 16x9 4K displays now… Didn’t that come from punchcards ???

ahoef 11mo ago
While 80 characters is obviously quite short, my experience is that longer line lengths result in much less readable code. You have to try to be concise on shorter lines, with better phrasing.
Sharlin 11mo ago
It did, but 80 columns also pretty closely matches the 50ish em/70ish character paragraph width that’s usually recommended for readability. I myself wouldn’t go much higher than 100 columns with code.
strogonoff 11mo ago
Come for punchcards, stay for legibility. 80 characters per line is an odd convention in the sense that it originated from a technical limitation, but is in fact a rule of thumb perfectly familiar to any typesetting professional from long before personal computing became widespread. Remember newspapers? Laying the text out in columns[0] is not a random quirk or result of yet another technology limitation. It is the same reason a good blog layout sets a conservative maximum width for when it is read on a landscape oriented screen. The reason is that when each line is shorter, the entire thing becomes easier to read. Indeed, even accounting for legibility hit caused by hyphenation. Up to a point, of course. That point may differ depending on the medium and the nature of the material: newspapers, given they deal with solid plain text and have other layout concerns, limit a line to around 50 characters; a book may go up to 80 characters. Given a program is not a relaxed fireside reading, I would place it closer to the former, but there are also factors and conventions that could bring acceptable line length up. For example, indentation and syntax highlighting, or typical identifier length (I’m looking at you, CNLabelContactRelationYoungerCousinMothersSiblingsDaughterOrFathersSistersDaughter), or editor capability to wrap lines nicely[1]. Finally, since the actual technical limitation is gone, it is actually not such a big deal to violate the line length rule on occasion. [0] Relatedly, codebases roughly following the 80 character line length limitation unlock more interesting columnar layouts in editors and multiplexers. [1] Isn’t the auto-wrap capability in today’s editors good enough that restricting line length is pointless at the authoring stage? Not really, and (arguably) especially not in case of any language that relies on indentation. Not that it could not be good enough, but considering code becomes increasingly write-only it seems unlikely we will see editors with perfect, context-sensitive, auto-wrap any time soon.
- Xss3 11mo ago
  80 chars per line was invented when languages used shortened commands though. Nowadays 120 is more appropriate. Especially in Powershell. Not so much in bash where commands are short, 80 can stay alive there!
  - strogonoff 11mo ago
    I think it does depend on language and typical identifier length, but I would say what I work with deserves 80 characters. If I was writing Swift for Apple ecosystem, I might go wider.
- PaulDavisThe1st 11mo ago
  When I read text I prefer it to use the lessons of typography and not be overly wide, lest my saccadic motion leads my immersion and comprehension astray. However when I read code I do not want to scan downwards to complete the semantics of a given expression because that will also break my comprehension and so when a line of code is long I'd prefer for it to remain long unless there are actually multiple clauses and other conditionally chained semantic elements that are more easily read alone
  - iknowstuff 11mo ago
    oof this looks awful on mobile, with extra line breaks
    - PaulDavisThe1st 11mo ago
      I don't know any way to force line breaks on HN without extra line breaks ... do you?
      - deleted 11mo ago
        [deleted]
      - deleted 11mo ago
        [deleted]
mavhc 11mo ago
Try explaining files to a kid these days
perching_aix 11mo ago
It really wouldn't be much of a conversation. Historical conventions are a thing in general. Just think of the direction of electron flow. > even though we have 16x9 4K displays now Pretty much no normal person uses those at 100% scaling though, so unless you're thinking of the fellas who use a TV for a monitor, that doesn't actually help so much: - 100% scaling: 6 panels of 80 columns fit, no px go to waste - 125% scaling: 4 panels of 80 columns fit, 64 px go to waste (8 cols) - 150% scaling: 4 panels of 80 columns fit, no px go to waste - 175% scaling: 3 panels of 80 columns fit, 274 px go to waste (34 cols) - 200% scaling: 3 panels of 80 columns fit, no px go to waste This sounds good until you need any additional side panels. Think line numbers, scrollbars, breakpoint indicators, or worse: minimaps, and a directory browser. A minimap is usually 20 cols/panel, a directory browser is usually 40 cols. Scrollbar and bp-indicator together 2 cols/panel. Line numbers, probably safe to say, no more than 6 cols/panel. With 2 panels, this works out to an entire additional panel in overhead, so out of 3 panels only 2 remain usable. That's the fate of the 175% and 200% options. So what is the "appropriate" scaling to use? Well PPI-wise, if you're rocking a 32" model, then 150%. If a 27" model, then 175%. And of course, given a 22"-23"-24" unit, then 200%. People of course get sold on these for the "additional screen real estate" though, so they'll instead sacrifice seeing the entire screen at once and will put on their glasses. Maybe you prefer to drop down by 25% for each of these. All of this is to say, it's not all that unreasonable. I personally feel a bit more comfortable with a 100 col margin, but I do definitely appreciate when various files nicely keep to the 80 col mark, they're a lot nicer to work with side-by-side.
SomeUserName432 11mo ago
You can make harddrives to A: and B: just fine. This will generally work with everything using the Win32 C api. You will however run into weird issues when using .Net, with sudden invalid paths etc.
account42 11mo ago
> Of course software developers are still stuck with 80 column conventions Speak for yourself, all my projects use at least 100 if not 120 column lines (soft limit only). Trying to keep lines at a readable length is still a valid goal though, even without the original technical limitations - although the bigger win there is to keep expression short, not to just wrap them into shorter lines.
UltraSane 11mo ago
The fact that modern interactive command shells are based on virtual teletype terminals is just absurd when you think about it
- 1718627440 11mo ago
  Why? You are communicating with a machine, and (formal) language is a good way to do precise communication. The initial medium to do these communication is not really all that relevant. The abstraction of putting a display into an two-dimensional array of primitive cells is also not limited to teletypes. Using characters instead of picture elements (commonly shorted to pixels) is not a bad choice when all you want to do is render text and means that your rendering code can be much simpler. That's the case independently of the earlier technology forcing this way. Teletype emulators also typically have a way of using pixels as the primitive (framebuffers). GUI Teletype emulators now don't, because there is a fine alternative to use pixels (the display server).
tracker1 11mo ago
If you don't have some level of arbitrary limit on line length, it becomes all that much easier to sneak in malicious code prefixed by a bunch of whitespace. Linting and autoformats help here... just allowing any length of line in code is just asking to get pwned at some point.
int_19h 11mo ago
Try explaining /usr to a kid these days. "That obviously means Users, so that's where the home directories are, right?" "Well, no. And it actually means Unix System Resources" (but historically it was in fact "user", just not in that sense) I'm sure we'll eventually bacronym C: as well.

ahoef 11mo ago

While 80 characters is obviously quite short, my experience is that longer line lengths result in much less readable code. You have to try to be concise on shorter lines, with better phrasing.

Sharlin 11mo ago

It did, but 80 columns also pretty closely matches the 50ish em/70ish character paragraph width that’s usually recommended for readability. I myself wouldn’t go much higher than 100 columns with code.

strogonoff 11mo ago

Come for punchcards, stay for legibility. 80 characters per line is an odd convention in the sense that it originated from a technical limitation, but is in fact a rule of thumb perfectly familiar to any typesetting professional from long before personal computing became widespread. Remember newspapers? Laying the text out in columns[0] is not a random quirk or result of yet another technology limitation. It is the same reason a good blog layout sets a conservative maximum width for when it is read on a landscape oriented screen. The reason is that when each line is shorter, the entire thing becomes easier to read. Indeed, even accounting for legibility hit caused by hyphenation. Up to a point, of course. That point may differ depending on the medium and the nature of the material: newspapers, given they deal with solid plain text and have other layout concerns, limit a line to around 50 characters; a book may go up to 80 characters. Given a program is not a relaxed fireside reading, I would place it closer to the former, but there are also factors and conventions that could bring acceptable line length up. For example, indentation and syntax highlighting, or typical identifier length (I’m looking at you, CNLabelContactRelationYoungerCousinMothersSiblingsDaughterOrFathersSistersDaughter), or editor capability to wrap lines nicely[1]. Finally, since the actual technical limitation is gone, it is actually not such a big deal to violate the line length rule on occasion. [0] Relatedly, codebases roughly following the 80 character line length limitation unlock more interesting columnar layouts in editors and multiplexers. [1] Isn’t the auto-wrap capability in today’s editors good enough that restricting line length is pointless at the authoring stage? Not really, and (arguably) especially not in case of any language that relies on indentation. Not that it could not be good enough, but considering code becomes increasingly write-only it seems unlikely we will see editors with perfect, context-sensitive, auto-wrap any time soon.

Xss3 11mo ago
80 chars per line was invented when languages used shortened commands though. Nowadays 120 is more appropriate. Especially in Powershell. Not so much in bash where commands are short, 80 can stay alive there!
- strogonoff 11mo ago
  I think it does depend on language and typical identifier length, but I would say what I work with deserves 80 characters. If I was writing Swift for Apple ecosystem, I might go wider.
PaulDavisThe1st 11mo ago
When I read text I prefer it to use the lessons of typography and not be overly wide, lest my saccadic motion leads my immersion and comprehension astray. However when I read code I do not want to scan downwards to complete the semantics of a given expression because that will also break my comprehension and so when a line of code is long I'd prefer for it to remain long unless there are actually multiple clauses and other conditionally chained semantic elements that are more easily read alone
- iknowstuff 11mo ago
  oof this looks awful on mobile, with extra line breaks
  - PaulDavisThe1st 11mo ago
    I don't know any way to force line breaks on HN without extra line breaks ... do you?
    - deleted 11mo ago
      [deleted]
    - deleted 11mo ago
      [deleted]

mavhc 11mo ago

Try explaining files to a kid these days

perching_aix 11mo ago

It really wouldn't be much of a conversation. Historical conventions are a thing in general. Just think of the direction of electron flow. > even though we have 16x9 4K displays now Pretty much no normal person uses those at 100% scaling though, so unless you're thinking of the fellas who use a TV for a monitor, that doesn't actually help so much: - 100% scaling: 6 panels of 80 columns fit, no px go to waste - 125% scaling: 4 panels of 80 columns fit, 64 px go to waste (8 cols) - 150% scaling: 4 panels of 80 columns fit, no px go to waste - 175% scaling: 3 panels of 80 columns fit, 274 px go to waste (34 cols) - 200% scaling: 3 panels of 80 columns fit, no px go to waste This sounds good until you need any additional side panels. Think line numbers, scrollbars, breakpoint indicators, or worse: minimaps, and a directory browser. A minimap is usually 20 cols/panel, a directory browser is usually 40 cols. Scrollbar and bp-indicator together 2 cols/panel. Line numbers, probably safe to say, no more than 6 cols/panel. With 2 panels, this works out to an entire additional panel in overhead, so out of 3 panels only 2 remain usable. That's the fate of the 175% and 200% options. So what is the "appropriate" scaling to use? Well PPI-wise, if you're rocking a 32" model, then 150%. If a 27" model, then 175%. And of course, given a 22"-23"-24" unit, then 200%. People of course get sold on these for the "additional screen real estate" though, so they'll instead sacrifice seeing the entire screen at once and will put on their glasses. Maybe you prefer to drop down by 25% for each of these. All of this is to say, it's not all that unreasonable. I personally feel a bit more comfortable with a 100 col margin, but I do definitely appreciate when various files nicely keep to the 80 col mark, they're a lot nicer to work with side-by-side.

SomeUserName432 11mo ago

You can make harddrives to A: and B: just fine. This will generally work with everything using the Win32 C api. You will however run into weird issues when using .Net, with sudden invalid paths etc.

account42 11mo ago

> Of course software developers are still stuck with 80 column conventions Speak for yourself, all my projects use at least 100 if not 120 column lines (soft limit only). Trying to keep lines at a readable length is still a valid goal though, even without the original technical limitations - although the bigger win there is to keep expression short, not to just wrap them into shorter lines.

UltraSane 11mo ago

The fact that modern interactive command shells are based on virtual teletype terminals is just absurd when you think about it

1718627440 11mo ago
Why? You are communicating with a machine, and (formal) language is a good way to do precise communication. The initial medium to do these communication is not really all that relevant. The abstraction of putting a display into an two-dimensional array of primitive cells is also not limited to teletypes. Using characters instead of picture elements (commonly shorted to pixels) is not a bad choice when all you want to do is render text and means that your rendering code can be much simpler. That's the case independently of the earlier technology forcing this way. Teletype emulators also typically have a way of using pixels as the primitive (framebuffers). GUI Teletype emulators now don't, because there is a fine alternative to use pixels (the display server).

tracker1 11mo ago

If you don't have some level of arbitrary limit on line length, it becomes all that much easier to sneak in malicious code prefixed by a bunch of whitespace. Linting and autoformats help here... just allowing any length of line in code is just asking to get pwned at some point.

int_19h 11mo ago

Try explaining /usr to a kid these days. "That obviously means Users, so that's where the home directories are, right?" "Well, no. And it actually means Unix System Resources" (but historically it was in fact "user", just not in that sense) I'm sure we'll eventually bacronym C: as well.