What explains the popularity of terminals with 80×24 and 80×25 displays? A recent blog post “80×25” motivated me to investigate this. The source of 80-column lines is clearly punch cards, as commonly claimed. But why 24 or 25 lines? There are many theories, but I found a simple answer: IBM, in particular its dominance of the terminal market. In 1971, IBM introduced a terminal with an 80×24 display (the 3270) and it soon became the best-selling terminal, forcing competing terminals to match its 80×24 size. The display for the IBM PC added one more line to its screen, making the 80×25 size standard in the PC world. The impact of these systems remains decades later: 80-character lines are still a standard, along with both 80×24 and 80×25 terminal windows.
As noted, a follow-up to our earlier discussion.
It also might be simpler.
Consider even now TVs are more common than monitors.
so there were factories producing the 3:2 ratio (something close to fibonacci) or even parts for them, so you have a landscape TV screen which you can adapt. Since the glyphs for the text characters are higher than wide, how do you optimally pack them onto the screen? And make them clear, readable, visible, distinguishabe, including 0 v.s. O. The 7×5 matrix is the minimum (yes there are attempts but they don’t look right). Even that doesn’t do glyphs below the line.
I remember getting a hi-rez monitor and doing 132×60 or more consoles as a text mode. They are there on the middle graphics cards.
Now I have a 4k monitor, and when I’m not in windows set the font to 8×8 and can see a lot.
Those of us oldies with an electronics background will be very familiar with delay lines. They were ubiquitous in quality analogue oscilloscopes as they allowed the oscilloscope user to see what happened just before the trigger point.
I’ve since upgraded to a 120-wide terminal but in programming many best practises suggest limiting lines in source code to 80 characters at least in one form or another.
80 chars as a hard limit is way too little, but it makes sense for comment lines because then long comments are formatted properly for all people working on that piece of code.
I’d argue that it depends on the programming language syntax. You’re also trading off against the ability to be able to split your monitor into multiple portrait-mode windows (eg. using Vim/gVim’s
:vsplitcommand).The Rust developers decided that 100 characters is a better compromise point for them and that’s what
rustfmtwill wrap to.I’m astonished that maximum line lengths are still a thing in programming style guides. They should have died out years ago. With all of their other complexities, you’d have thought modern IDEs would be able to wrap lines dynamically while still maintaining neat indentation and comment blocks.
flypig
+1
Any fixed length is wrong. I often use different devices with different screen sizes. Even with a single monitor the window size changes based on the activity. Sometimes I will code with windows side by side. A fixed line length is just no good.
Granted, not all text editors are equal in sophistication to handle code wrapping, but the best practice is for editors to handle it responsively and not force a fixed line length, just like websites.
https://www.w3schools.com/whatis/whatis_responsive.asp
Personally I divide lines up by conceptual blocks instead without regards to line length. It can be shorter or longer than 80, I pay no attention to it and I don’t care because the logical organization is far more important to me than line length.
“Any fixed length is wrong. I often use different devices with different screen sizes. Even with a single monitor the window size changes based on the activity. Sometimes I will code with windows side by side. A fixed line length is just no good.”
So you’re adopting the communistic approach that if SOME displays / hardware cannot handle the chosen line length, then NONE of the displays are allowed to be able to do that? That’s obviously the wrongest way to go.
The utopistic solution proposed by dear @flypig is something I’ve never came across. Actually I haven’t even seen a text editor capable of integrating a linter properly. Until features like these are actually mainstream and not limited to one or two highly opinionated IDEs, then they obviously cannot be a hard requirement.
It is about simple code formatting and formatting is always going to be something explicit anyways, either you do it manually or use a tool that does it for you, but it has to be written into the source file and not left for the display phase.
Handling line length isn’t really different from typing a space around an operator, choosing whether to place the curly brace on the same line following a function name or on its own, or what indentation level and style to use. All of these tasks could — in theory — be left for the IDE to perform on-the-fly but that’s just not reality.
I wonder if @flypig even ever wrote any code at all…
sj87,
No, it’s actually
the most flexible
way in terms of
allowing the editor
to wrap the code at
the most suitable
point for any given
window rather than
making assumptions.
It isn’t practical
to unwrap code after
it has been wrapped,
therefor it makes
the most sense to
wrap it when it is
rendered rather than
hard coding the line
width.
Note: I preformatted my text this way just to hammer home the point that preformatting can not only be more cumbersome to edit, but also more cumbersome to read. It is tedious to work with such preformatted text. Say you insert/delete a word in a multiline string, normally an editor will re-wrap the text automatically according to your preferences, but with pre-formatted text you have to manually bump words across line boundaries in order to renormalize the arbitrary line boundaries. It makes absolutely no sense to have users micromanaging word-wrapping to an arbitrary fixed column standard in this day and age. This may have made more sense when everyone was using the same 80×25, but now it’s a waste of time and energy and we’ve got better things to focus on such as breaking the code up into less arbitrary and more logical units that I was talking about.
Actually on the fly code formatting IS a reality if you’ve got an IDE that does it. Visual studio has done this for a while now, for example. Eclipse also has an auto code formatter, although it works a bit differently.
https://www.youtube.com/watch?v=2DkRiLFKZbA
Long story short, you do what’s best for you, I’ll do what’s best for me.
That’s a strawman…
I’ve never come across it done well either, but that doesn’t mean it couldn’t be and @Alfman’s VS video shows the potential. But I actually agree with you that the change in IDEs will likely have to come first.
I disagree. I’m even still surprised that code for modern programming languages is stored in text files. I understand the arguments about version control, diffs, existing tooling and the need for badly-formed code during editing, but in my opinion that’s an accident of history. It would make just as much sense to store committed code as an AST with formatting applied at edit or render time. With the growth in students learning Scratch in schools, I actually think the likelihood of this changing is increasing.
I dunno. Maybe you could click on my profile name and check.
But @Alfman is right about this too: better to focus on the game rather than the players.
flypig,
Intriguing. I think something like that could work too, although there would be a great deal of resistance in our field. Hell, we haven’t even gotten rid of some of the worst anti-patterns of C and we’ve had decades to observe it’s deficiencies in the wild.
But in niche cases anyways maybe there could be other ways of programming with higher level abstractions rather than by typing text that could improve our efficiency. There’s no implication that text is the best way to do things, it’s just a convention. Industrial engineers program PLCs with ladder logic, which has no basis in textual code and can be more robust than C for those programming it.
https://www.youtube.com/watch?v=qaI48NCUvkA
PLC ladder logic is too specialized for general purpose programming, but I think software development could evolve beyond text if there were the will. Given the capabilities of AI today, it could really change the game from focusing on low level constructs to more high level abstractions, which is something we’ve seen before in the form of OOP but we still haven’t evolved much past text editing. Maybe the computers should be solving the software problems and writing the algorithms. The role of the programmer may change from inputting code to inputting high level requirements.
“flypig
I’m astonished that maximum line lengths are still a thing in programming style guides. They should have died out years ago. With all of their other complexities, you’d have thought modern IDEs would be able to wrap lines dynamically while still maintaining neat indentation and comment blocks.”
Yeah, and what you will end up with is an unreadable mess the moment you try to do anything useful with it like printing it out…….
yoko-t,
Who does that any more? The last time I printed code was in college, and even then I found it kind of old-fashioned. Anyways, this isn’t really an impediment when you have an editor that supports smart wrapping.
A fixed line length implicitly favors a fixed font and canvas size ratio, but neither of those are static in practice and there’s a lot of diversity including the printing that you brought up! This isn’t hypothetical at all. On a wide screen monitor, 80 characters is often too small and it can be annoying when linesize has to artificially constrained. Yet on a small screen or on a medium that uses a huge font size (such as a presentation) 80 characters can be too many and you end up with automatic wrapping on top of manual wrapping, which is really jarring.
To say that 80 characters is good enough for everyone is kind of naive, because it really is not everywhere. In one of my previous posts I posted an example where the word wraps were manually added such that they were appropriate on my android phone in portrait mode, but as you can see it looks ridiculous on a computer and the opposite is true too.
The best solution is to have a responsive editor that wraps text according to window size to alleviate programmers of this hassle. I would agree with the sentiment that many text editors aren’t as good as they should be. But never-the-less we need to focus on getting editors to fix word wrapping deficiencies, not wasting the programmer’s time to do it statically & manually, that’s an obsolete solution.
What? No. Line length limits are there exactly to allow vertical split of windows. Any modern laptop can easily do at least 2 x 100 characters if not more. Those who “want to go deeper” should just invest into an additional physical display.
Well, I certainly called it… half way. The whole article boils down to two things: 80×24 fits in 2KB, which I mentioned the last article on this, but then they also point out that they had a 40×12 terminal that they simply doubled vertically and horizontally to 80×24, so there was also the “cheaper to make from existing hardware” angle to go with the “fits in ram” angle.