Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

But no, 80-column terminals in 2020 isn't “reasonable” any more

lkml.org

Post reply on HN
Print view View original

311–320 of 330 posts

Re: But no, 80-column terminals in 2020 isn't “reasonable” any more

#311

Post by taeric »

fauigerzigerk wrote: post #258
taeric wrote: post #236

Earlier quoted context omitted.

Same is true for most all reading. Skim then read, is a predominant form is reading. Is why newspapers scatter their stories throughout. Indeed, they punish linear reading... Recipes often do two columns of some things. Math jargon is all about repetition. Narrative, explanation, exposition. Don't get me wrong, I am inclined to agree with you. But we don't have a ton of empirical evidence on our side.

>But we don't have a ton of empirical evidence on our side Neither does the other side, unless you accept the premise that reading natural language text is similar enough to reading heavily indented code where that indentation has meaning. I don't accept that at all. The studies that were done on natural language text assume that line length is equal to the column where the line ends (i.e all lines begin on the left…

My point was that there is no writing that extends to long lines. If anything, the fact that no other writing form has made such extensive use of indentation is enough to give me pause and think if that is making any sense. (I do note the amusing lines in the Linux style guide on the use of heavy indentation.)

And looking at this before I hit go. You seem to ultimate be agreeing. Taking opening indentation into consideration concedes that long lines are bad. You just give some room for margins. And are ok with all of the mental stacking that the indentation implies.

Re: But no, 80-column terminals in 2020 isn't “reasonable” any more

#312

Post by jacobsenscott »

leghifla wrote: post #201
jacobsenscott wrote: post #128

Earlier quoted context omitted.

I've also been buying a larger monitor every few years, as the prices drop. But I hated the 42" 4K I tried and returned it. The problem was the edges are just too far away. If I use them I end up with the same kind of neck strain I would get with a multi-monitor setup. So I only used kind of the middle section of the screen anyway. And at 42" 4K the physical pixels are just too big - everything is fuzzy. 32" 4K is th…

Do you know if your neck strain is due to horizontal or vertical movements? On a few times I had to work with big monitors (>30"), I noticed that I placed/sized windows only at the center, and not all the way to the top. Looking up too much is not comfortable for my neck. For the horizontal movement, I have no problem. But when my eyes are focused on the centre part, if I need to look at the extreme left/right, I nee…

The vertical was definitely more uncomfortable than horizontal.

Re: But no, 80-column terminals in 2020 isn't “reasonable” any more

#313

Post by Avamander »

u801e wrote: post #309
Avamander wrote: post #292

Earlier quoted context omitted.

After reading that, I'm really thankful that git-by-email is dying. Hard wrapping is just really terrible for anyone not using a VT-100.

I'm pretty sure that most people would prefer their code hard-wrapped at a certain line length.

That's a rather useless sentence if I'm being honest, most people would prefer their code bug-free as well.

In the end, normal programmers don't write 1000char lines and do format their code nicely. Any limits should be soft, pedantic hard-wrapping at some arbitrary character count is just harmful.

In the case of non-code, no, absolutely no hard wraps, people using phones, accessibility features or similar non VT-100 deserve readable text, not some disgustingly formatted column.

Re: But no, 80-column terminals in 2020 isn't “reasonable” any more

#314

Post by Avamander »

u801e wrote: post #308
Avamander wrote: post #301

Earlier quoted context omitted.

> It just sounds like you don't like the process since you apparently aren't able to express a specific issue with it. I don't like the process because it has so many issues. It's just hostile in so many ways if you aren't using a VT-100, it's fundamentally flawed because of the assumptions it makes. > I would certainly be interested to read your specific complaints about the email based process instead of just a dis…

> I don't like the process because it has so many issues And you still haven't described any of them. > It's just hostile in so many ways if you aren't using a VT-100 That's a strawman. At some point, you're going to have to use git on the command line to stage code, push it up to the remote or pull new code from the remote. You're going to have to learn how to deal with code conflicts, resolve them and push up the r…

> That's a strawman

How? That workflow assumes a 80-char b/w terminal for the most part. Try using any part of it on mobile or with large font size due to bad eyesight, it's awful.

> At some point, you're going to have to use git on the command line to stage code, push it up to the remote or pull new code from the remote.

Well... no, you don't have to.

> In my case, I have no problem doing this through the email account I have with my ISP.

In your case...

> The problem is that you're being too dismissive in your criticism and comments rather than specifically describing what could be improved within their process.

I have tried being very specific, just one sentence later you prove my point, it doesn't work and gets dismissed. I really don't plan on playing that game until I die of old age. Thankfully GitLab/GitHub et al have started the "fight" for me, making the workflows much more accessible and losing quite a few B/G-era relics.

> Effectively telling a project that they need to discard a process that they've successfully used since its inception and move to an entirely new process is a non-starter.

Yeah, this is exactly the answer I spoke about and have gotten, blanket dismissal and being set in old ways. There isn't a piece of workflow that they're/you're willing to move out of that toolset. Quite a few projects still enforce 80char columns, it's a testament to the fact that even the smallest things can't be changed.

> A lot of Webapps perform worse in terms of latency and input lag on my laptop with a multicore processor, gigabytes of memory and over a terabyte of secondary storage compared to the equivalent desktop application from decades ago on a machine with megabytes of memory, a single core processor running at less than a quarter GHz and secondary storage less than a quarter GB.

Yeah and you uploaded your patchsets for minutes if not hours. God forbid you had to download anything with any size at all, sometimes it took days. The non-stop hassle of having enough disk space. Delivering files via snail-mail and floppies was sometimes a viable option. Not to mention the equal amount of rather buggy and cumbersome software.

It wasn't all bunnies and flowers you are trying to imply it was. Some half-a-second slowdown, some minor input latency is not a valid reason to dismiss an entire set of tools. Not to mention, git doesn't really shine with it's responsiveness in quite a few cases.

Re: But no, 80-column terminals in 2020 isn't “reasonable” any more

#315

Post by yellowapple »

js2 wrote: post #49

The problem with overly wide lines is that it hurts readability because it's harder to find the next line when scanning your eyes from right back to left. Take it from the world of books: This study may be helpful: > This study examined the effects of line length on reading performance. Reading rates were found to be fastest at 95 cpl. Readers reported either liking or disliking the extreme line lengths (35 cpl, 95 c…

> The problem with overly wide lines is that it hurts readability because it's harder to find the next line when scanning your eyes from right back to left.

This is indeed why a large number of books and articles and papers opt for multiple-column formats.

Frequent line breaks also help better break up distinct pieces that warrant independent examination, much like how such breaks in poetry help isolate distinct thoughts. There are certainly cases where such a "thought" does indeed exceed that 80-line limit, but I've found that they are rare (though this obviously depends on the language; for example, in my day job my T-SQL code frequently exceeds that arbitrary limit, simply because it often takes more characters to express a "thought").

All that being said, I wouldn't impose this on an existing project. If Linux's standard is for 100-character lines, then that is the standard to which I'll adhere. For my own code, however, 80 characters is (language limitations notwithstanding) more than sufficient.

Re: But no, 80-column terminals in 2020 isn't “reasonable” any more

#316

Post by yellowapple »

im3w1l-alt wrote: post #251
deepspace wrote: post #246

Earlier quoted context omitted.

To be fair though, if you have class names like AbstractSingletonProxyFactoryBean, then terminal width is the LEAST of your problems.

You may be in a position where using a verbose framework or libraries save you way more effort than the small pain they bring.

You may also be in a position where you can alias those names to something more reasonable.

Re: But no, 80-column terminals in 2020 isn't “reasonable” any more

#317

Post by yellowapple »

zeroimpl wrote: post #242
DoubleGlazing wrote: post #124

I think this is a subject most editors fail to address. A single line of code should be written to file as a single line - no matter how long. However, the editor you are using should be able to gracefully word wrap it depending on your settings. Most editors word wrap based on window size or some other hard setting. They should be able to wrap gracefully at a logical point in the code e.g. at a comparison operator o…

This would make debugging hard, as debuggers are very much line number based. Step commands move one line at a time, breakpoints are for specific lines, and stack traces from exceptions include line numbers but not character offsets. That’s why for function calls passing multiple arguments where each argument may be non trivial, it’s a good idea to put each argument on its own line.

The editor could show both the final line number and "sub-line-numbers" after a decimal point or something. E.g.:

    1   /* A function that does something */
    2.1 int do_something(int foo,
    2.2                  int bar,
    2.3                  int baz)
    2.4 {
    2.5     return foo + bar + bam;
    2.6 }
Which would condense to:

    1    /* A function that does something */
    2    int do_something(int foo, int bar, int baz) { return foo + bar + bam; }
When you try to compile this, the compiler will complain about line 2, which you know from your editor's line numbering encompasses lines 2.1 through 2.6. As an alternate strategy, you could use column numbers instead of sequential sub-lines, like so:

    1    /* A function that does something */
    2.0  int do_something(int foo,
    2.26                  int bar,
    2.35                  int baz)
    2.44 {
    2.46     return foo + bar + bam;
    2.70 }
And then, if the compiler reports a column number or offset into the line, you'll immediately know "well the compiler's complaining about line 2 column 65, which is between 2.46 and 2.70... golly gee willikers, I fat-fingered the third addend in the return statement!".

You could get even more abstract than this, with "line numbers" instead being local to a given scope, and the compiler reporting erroneous line numbers relative to said scope. If the compiler tells you that the syntax error is in the first (in this case also last) statement in the function do_something, then it should be apparent where to look.

Re: But no, 80-column terminals in 2020 isn't “reasonable” any more

#318

Post by u801e »

Avamander wrote: post #314
u801e wrote: post #308

Earlier quoted context omitted.

> I don't like the process because it has so many issues And you still haven't described any of them. > It's just hostile in so many ways if you aren't using a VT-100 That's a strawman. At some point, you're going to have to use git on the command line to stage code, push it up to the remote or pull new code from the remote. You're going to have to learn how to deal with code conflicts, resolve them and push up the r…

> That's a strawman How? That workflow assumes a 80-char b/w terminal for the most part. Try using any part of it on mobile or with large font size due to bad eyesight, it's awful. > At some point, you're going to have to use git on the command line to stage code, push it up to the remote or pull new code from the remote. Well... no, you don't have to. > In my case, I have no problem doing this through the email acco…

> How? That workflow assumes a 80-char b/w terminal for the most part.

There's nothing stopping you from using a gui text editor to edit the code and there's nothing in git commits or the code itself that forces wrapping at 80 characters. Email clients certainly can wrap text at longer line lengths if configured to do so.

> Try using any part of it on mobile or with large font size due to bad eyesight, it's awful.

I don't try to do any serious development on my mobile. Having a machine with a reasonable size screen along with an actual keyboard makes things much easier.

If you're referring to hard wrapping, you're probably going to have to deal with that for most source code anyway no matter what line length. Soft-wrapping lines that exceed the screen width makes code and diffs less readable. For text in the email that doesn't require hard wrapping, there is an RFC[1] that defines a additional format parameter for the Content-Type header. Clients that support it will softwarp text, but email clients that don't will just show the original hardwrapped version.

> I have tried being very specific, just one sentence later you prove my point, it doesn't work and gets dismissed.

The git project, specifically, has been using this process since its inception (around 2005 IIRC). They inherited it from the Linux project which had been around for several years longer than that. In fact, the process pre-dates git itself and git was written with that process in mind (which is why they have commands that can serialize commits to and deserialize them from email).

But, like I said, telling a group of people as an outsider that they should drop the long standing process entirely which has been working well for them and go with something different isn't going to gain any real traction. This is regardless of the domain you're dealing with.

> Yeah and you uploaded your patchsets for minutes if not hours.

Most patch sets probably don't exceed several hundred lines total. Even on dial-up, you're talking about less than a minute.

> God forbid you had to download anything with any size at all, sometimes it took days.

Patch sets aren't really that big. The only thing that took a while with email or newsgroups was messages with attachments or having to download a lot of headers. As for git, the only process that may take a while is git clone. git fetch and dealing with email would work just fine over dial-up.

On the other hand, I seriously doubt that webapps like Github or Slack can work over dial-up speeds. For instance, if I have people at home streaming video while I try to use Slack or Github, they're essentially not usable, but I can still receive and send email without any issues.

> It wasn't all bunnies and flowers you are trying to imply it was.

If you were talking about downloading images, mp3s, etc, then, yes, it took a while, but those things aren't relevant to text patches, email, or git.

> Some half-a-second slowdown, some minor input latency is not a valid reason to dismiss an entire set of tools.

I use Slack and Github Enterprise at work. On a 100 Mbps downstream connection, I have to wait for 10 to 20 seconds for a PR to load up when it has more than 20 comments. When I type in Slack, there's a noticable input lag that develops over time (on the order of seconds) and I have to refresh the Slack window several times a day to get rid of it). Sometimes, I try to mark messages as read and my browser tab freezes until it gives me a prompt about a script causing a slowdown. If I stop it, then Slack is unusable and I have to refresh the page to recover.

I simply don't recall having these issues with email or IRC (or even some of the other chat clients like ICQ, AIM, MSN Messenger, etc), and all of them worked perfectly fine over dial up and on machines that significantly less computation speed and available memory.

> Not to mention, git doesn't really shine with it's responsiveness in quite a few cases.

It really depends on what you're using git for. If you're storing large binary files or very big mono-repos, then it's not the right tool to use. Similarly, tools like Github aren't the right tool to use for certain projects that deal with many in flight patch sets that require in depth discussion and not having the platform shut down accounts of certain users due to issues the US government has with a number of other countries around the world.

[1] https://tools.ietf.org/rfc/rfc3676.txt

Re: But no, 80-column terminals in 2020 isn't “reasonable” any more

#319

Post by Avamander »

u801e wrote: post #318
Avamander wrote: post #314

Earlier quoted context omitted.

> That's a strawman How? That workflow assumes a 80-char b/w terminal for the most part. Try using any part of it on mobile or with large font size due to bad eyesight, it's awful. > At some point, you're going to have to use git on the command line to stage code, push it up to the remote or pull new code from the remote. Well... no, you don't have to. > In my case, I have no problem doing this through the email acco…

> How? That workflow assumes a 80-char b/w terminal for the most part. There's nothing stopping you from using a gui text editor to edit the code and there's nothing in git commits or the code itself that forces wrapping at 80 characters. Email clients certainly can wrap text at longer line lengths if configured to do so. > Try using any part of it on mobile or with large font size due to bad eyesight, it's awful. I…

> there's nothing in git commits or the code itself that forces wrapping at 80 characters

Very clever leaving out the third component here that does force it.

> Email clients certainly can wrap text at longer line lengths if configured to do so.

Assuming someone hasn't banally pre hard-wrapped the text.

> I don't try to do any serious development on my mobile.

Who said anything about serious development, you basically can't even check a patch out on mobile without some major hassle. Plus you also ignored the general accessibility problems.

> If you're referring to hard wrapping, you're probably going to have to deal with that for most source code anyway no matter what line length.

Source code can be displayed using a code viewer, nicely, it works. Comments can be displayed using a text viewer, using text fonts, nicely, it works. Non-HTML e-mail conflates the two, the resulting amalgam is vomit-inducing.

> But, like I said, telling a group of people as an outsider that

Nah, this reply is given to even insiders that don't want to deal with that obsolete shit.

> they should drop the long standing process entirely which has been working well for them and go with something different isn't going to gain any real traction. This is regardless of the domain you're dealing with.

I can say my ten-year-old laptop "works so far", but is it good, no, not really. It's really a rather weak argument to resist even changing the tiniest things.

> if I have people at home streaming video while I try to use Slack or Github, they're essentially not usable

Fix your home network.

> but those things aren't relevant to text patches, email, or git.

You're still pretending that it was fast even with text patches, e-mails or git.

> simply don't recall having these issues with email or IRC (or even some of the other chat clients like ICQ, AIM, MSN Messenger, etc), and all of them worked perfectly fine over dial up and on machines that significantly less computation speed and available memory.

Yeah, you have other issues with IRC. Not to mention, no, they didn't "work perfectly over dial-up".

> It really depends on what you're using git for. If you're storing large binary files or very big mono-repos, then it's not the right tool to use.

It depends if you're using it or not. It's slow even on medium-sized repositories. Things don't happen in an instant like you pretend them to do.

Re: But no, 80-column terminals in 2020 isn't “reasonable” any more

#320

Post by cdaven »

js2 wrote: post #49

The problem with overly wide lines is that it hurts readability because it's harder to find the next line when scanning your eyes from right back to left. Take it from the world of books: This study may be helpful: > This study examined the effects of line length on reading performance. Reading rates were found to be fastest at 95 cpl. Readers reported either liking or disliking the extreme line lengths (35 cpl, 95 c…

> Reading rates were found to be fastest at 95 cpl.

They only tested 35, 55, 75, and 95 characters per line (cpl)! Which means that if they had tested 120 cpl, THAT could have been "fastest".

Post reply on HN