The 80-character limit may have come from punchcards, but it's still important in 2018. It allows me to have three side-by-side columns of code, and I know I'm not alone. Even 100-character limit would break similar setups.
Furthermore, I personally find a lot easier to read code that is not too spread horizontally. I do not have extensive experience with Lisp or Clojure, but all languages I've worked with will handle a "small" line width of 80 character just fine most of the time.
I do recognize this is a matter of personal preference, but please don't dismiss the 80-character limit because it's old. It may be, but it is still relevant.
Other than that, I wholeheartedly agree with the post. I started toying around with clojurescript for the past few months, and the one thing I can't wrap my head around is its formatting. Sometimes one space, sometimes two. Sometimes block spacing. It's very confusing.
We expanded our team line limit to 88 characters and that feels quite a bit better than 80. There are a lot of pretty common lines of code that once you're nested in a function/if statement/loop stretch out beyond 80 characters but fall comfortably into 88.
I used to use 100 characters as my limit and it was pretty nice. I switched back to 80 because most editors already mark the 80 character point and I didn't want to have to configure editors (basically laziness). I find 80 fine for most code. There are some cases where I naturally go over a little and its a bit clumsy to avoid it, but they're few enough that I don't care. Especially in Clojure code, I find that if things are that long, then its too nested and hard to follow anyway and I rearrange my code (use ->, ->>, let etc to split nested forms up).
In Clojure code, the most likely reason to go over 80 characters for me is let forms like (let [long-descriptive-names-that-get-too-close-to-80 (and we-have-hit the-limit)])
but overly long names mess the code up anyway and should be avoided. Descriptive is good, but too long makes it hard too read too.
> all languages I've worked with will handle a "small" line width of 80 character just fine most of the time
Guessing you don't write Java? While you could do it, you'd have so much line wrapping that I imagine it would be much more annoying/difficult to read.
I think the argument the article was making wrt 80 is that editors can wrap the text to 80 characters without modifying the source, not that you shouldn't want your code to fit in 80 characters.
The counterargument is that they suck at it, you get a break (maybe word-aligned) with an arbitrarily indented next line.
As a purist I advocate for a future with smarter editor soft wrapping.
What editor should do is automatically scroll horizontally to hide the indentation and keep the code line in sight, as you move up and down through different indentation levels.
The thing is, code in the body of a function is rarely 80 columns long from the first non-whitespace character to the end of the line.
What would be useful would be a text editing mode that automatically scrolls horizontally to keep the code in view, regardless of indentation amount. Then you can have your 80 column window.
What sucks is moving down in a body of code, and watching the text disappear out to the right because the cursor is tracking straight down through the indentation instead of riding to the right of it.
That would do nothing to help the "I can't see all the code at once because it's bleeding off the side of the screen" problem. You'd just end up with getting to use a different set of keys, and slightly fewer keystrokes, to choose between not getting to see either the start of some lines or the end of some lines, which is a marginal improvement at best.
And I'm guessing it would only worsen the problem of sprawling code that's difficult to read, by removing one of the few sources of pain that encourages developers who are less mindful of what it's going to be like for the person who'll have to read this stuff 3 years down the road to exercise at least a little bit of care.
I can't see all the code at once because it's 80,000 lines and I have a 50 line peephole; so the "see all the code at once" has sailed. Roughly speaking, Lisp code grows diagonally:
When I move the cursor down. If the box would move diagonally, that would be great. Yes, of course the box will have empty space at the bottom left and top right.
That could be addressed in a funky way: why not rotate the text about 45 degrees? Then the rectangular window would capture a fuller slice of the diagonal. I could get used to the rotated text.
We may be at a cultural impasse, here. I see code that's nested that deeply, and it just makes me want to close the editor and go find something else to do.
Whether it's single lines that make a beeline for the pure land in the east, or towering ziggurats of stacked contexts slowly plodding their way into the sky, it doesn't really matter all that much to me. I count both of them as "sprawling code that's difficult to read." Lisp's a functional language; it's totally acceptable to break things up with a `defun` (or I guess, in this case, `defn`) here and there.
Furthermore, I personally find a lot easier to read code that is not too spread horizontally. I do not have extensive experience with Lisp or Clojure, but all languages I've worked with will handle a "small" line width of 80 character just fine most of the time.
I do recognize this is a matter of personal preference, but please don't dismiss the 80-character limit because it's old. It may be, but it is still relevant.
Other than that, I wholeheartedly agree with the post. I started toying around with clojurescript for the past few months, and the one thing I can't wrap my head around is its formatting. Sometimes one space, sometimes two. Sometimes block spacing. It's very confusing.