I’ll be interested to see if Neovim is able to cherry-pick this Vimscript work and get the best of both worlds: performant Vimscript for backwards compatibility and/or new users migrating from Vim, and performant Lua for greenfield config/plugin work.
That’s somewhat unfortunate, but I get it! Probably a large undertaking for a relatively small perceived benefit, especially given the trend towards “Lua all the things” in the nvim community.
All things equal, I think most people would (objectively) prefer to write Lua (applicable elsewhere) vs Vimscript (niche, doesn’t have modern language features currently, etc…), especially if you’re starting circa 2022 without any legacy baggage.
That said, I also understand Vim’s/Bram’s prioritization of backwards compatibility!
IME vim9script is not backward compatible with legacy vimscript. They can call functions defined in the other language but that has been true of vimscript and lua for years. I think the lack of lua scripts for years. I think the primary reason people have preferred vimscript over the various other supported languages is that FFI details are difficult to get a feel for when also trying to make something new. It’s easier to keep track of quirks in the code you have in your visual frame than it is to keep track of quirks that only exist within the FFI bridge.
These language improvements seem to suggest the scripting interface will also provide type safety when you call vim builtins. I have to imagine that’s either been missing from neovim, or it’s a lot of neovim-maintained validation definitions that could have mistakes. I’d definitely want to get this benefit from the first party.
OMG, @nbardiuk this is so great! Thank you so much! Well worth the $40. I’m on page 35 and I can already see that this is the most idiotic and ridiculous book about OOP I’ve ever read. Expect a fun blog posts as soon as I finish!
Our result
simply states that the order in which unit tests and
production code are written may not be as important
as commonly thought so long as the process is iterative,
granular, and uniform. Therefore, the developers could
follow the approach they prefer while paying particular
attention to step size and keeping a steady rhythm.
This matches my experience working with Clojure REPL that provides fast feedback on running application. I can quickly check how the changed code works similarly to small test. Small iterations are more important than sequence when tests are written.
A test-first dynamic may
provide long-term advantages not addressed by or detected in our study.
This is important point. In my experience TDD codebases have better tests and more maintainable production code. TDD is a good process to learn how to write testable code.
For most of languages I use LSP.
The main advantage is that it understands the language and knows where to find definitions, find usages, perform renames, display documentation.
The disadvantage is that some implementations of servers are slow, (or all of them are slow, depends on your definition of slow).
Yeah, 72 is much more reasonable.
We need hard limits, or at least ‘annnoying’ conventions to keep the horrors at bay. The human eye scans lines best at around 72 characters wide, and we should put human readability of our code before other concerns. I have worked on projects that had huge long lines and there is no excuse. If a language or tool or whatever can’t deal with human limits, find or make another tool. Linus’ current workstation should not be the standard.
That being said, I think Racket has made a reasonable compromise:
A line in a Racket file is at most 102 characters wide.
If you prefer a narrower width than 102, and if you stick to this width “religiously,” add a note to the top of the file—right below the purpose statement—that nobody should violate your file-local rule.
This number is a compromise. People used to recommend a line width of 80 or 72 column. The number is a historical artifact. It is also a good number for several different reasons: printing code in text mode, displaying code at reasonable font sizes, comparing several different pieces of code on a monitor, and possibly more. So age doesn’t make it incorrect. We regularly read code on monitors that accommodate close to 250 columns, and on occasion, our monitors are even wider. It is time to allow for somewhat more width in exchange for meaningful identifiers.
The human eye scans lines best at around 72 characters wide
I would like to have 72 chars wide line but with ignored indentation. It would make nested block readable on its own.
Example with 40 chars width ignoring indentation white space
Lorem ipsum dolor sit amet, consectetur
adipiscing elit. Donec sit amet augue
felis. Suspendisse a ipsum et sem auctor
porttitor in ac lacus.
Curabitur condimentum augue diam, ut
molestie nibh faucibus nec. Aliquam
lacinia volutpat tellus, non
sollicitudin nulla luctus sit amet.
Aenean consequat ipsum sem, ac rutrum
leo dictum at. Suspendisse purus dolor,
condimentum in ultrices vel, egestas vel
ipsum.
Versus 40 chars width including indentation
Lorem ipsum dolor sit amet, consectetur
adipiscing elit. Donec sit amet augue
felis. Suspendisse a ipsum et sem auctor
porttitor in ac lacus.
Curabitur condimentum augue diam, ut
molestie nibh faucibus nec. Aliquam
lacinia volutpat tellus, non
sollicitudin nulla luctus sit amet.
Aenean consequat ipsum sem, ac
rutrum leo dictum at.
Suspendisse purus dolor,
condimentum in ultrices vel,
egestas vel ipsum.
100% agreed. As I argued in the comments above, people don’t read code the same way that they read prose, and so I would not try to generalize a heuristic meant for prose to code.
I agree. Reading written text involves repeatedly shifting your focus to the line below. A consistent and short line length in that case is very important. Code is not the same. It’s far more common reading code to study a single line or small block, and in that case, I find that arbitrarily wrapping a line to stay within 80 characters usually breaks consistency and harms readability. I used to subscribe to the 80 character limit until I realised this difference. We don’t read code like we read written text.
Terminal/editor windows side by side is a fine point, but in general the vast majority of lines of code are short anyway, often well under 80 characters. If a few lines happen to wrap on your display, I hardly think that’s going to completely kill readability, and it’s certainly a trade-off I’m willing to make. If many lines are wrapping then yes, you probably have a problem with your code formatting (or your code in general). It’s the hard limit that I take issue with. Back when I wrote my own code like this, all too often I would find myself renaming identifiers (usually for the worse) among other arbitrary and unhelpful things, just to fit some code within a line without wrapping. I wouldn’t be surprised if more often than not this is the outcome for many others who attempt this, and it’s almost certainly a net negative for readability. Dropping the idea entirely has been a huge relief. One less thing to think about. Most of my code still consists of short lines, as it always did, and as most code naturally does. But when I need to, and it makes sense to write a longer line, I don’t spend a second agonising over whether it fits within some special number of characters, and instead focus entirely on whether it in itself is clear and understandable.
The human eye scans lines best at around 72 characters wide, and we should put human readability of our code before other concerns.
Recently, I have been trying to optimise my on-screen experience and I found a series of peer-reviewed articles with recommendations that improved my experience.
In one of those, it is claimed, indeed, that more than 72 and less than 80 characters (precisely, 77) is the optimal number for clear readability.
The study is for dyslexic people, and I was never diagnosed as so. But it works for me, and I tend to believe it works for most people as well.
Yeah what I’ve read confirms this, I think the width of the text column can vary based on the character width. For example in CSS I typically set something like:
I’ll be interested to see if Neovim is able to cherry-pick this Vimscript work and get the best of both worlds: performant Vimscript for backwards compatibility and/or new users migrating from Vim, and performant Lua for greenfield config/plugin work.
I remember hearing in a presentation that neovim team does not want to spend time on Vimscript 9. Here is one issue mentioning that it is not a priority https://github.com/neovim/neovim/issues/13625, and a wiki https://github.com/neovim/neovim/wiki/Merging-patches-from-upstream-Vim#types-of-not-applicable-vim-patches stating that patches with Vimscript 9 are “Not Applicable”
That’s somewhat unfortunate, but I get it! Probably a large undertaking for a relatively small perceived benefit, especially given the trend towards “Lua all the things” in the nvim community.
All things equal, I think most people would (objectively) prefer to write Lua (applicable elsewhere) vs Vimscript (niche, doesn’t have modern language features currently, etc…), especially if you’re starting circa 2022 without any legacy baggage.
That said, I also understand Vim’s/Bram’s prioritization of backwards compatibility!
IME vim9script is not backward compatible with legacy vimscript. They can call functions defined in the other language but that has been true of vimscript and lua for years. I think the lack of lua scripts for years. I think the primary reason people have preferred vimscript over the various other supported languages is that FFI details are difficult to get a feel for when also trying to make something new. It’s easier to keep track of quirks in the code you have in your visual frame than it is to keep track of quirks that only exist within the FFI bridge.
Vimscript 9 support is explicitly a non goal of the project charter.
These language improvements seem to suggest the scripting interface will also provide type safety when you call vim builtins. I have to imagine that’s either been missing from neovim, or it’s a lot of neovim-maintained validation definitions that could have mistakes. I’d definitely want to get this benefit from the first party.
It may be possible to write compiler for vim9 in Lua and then use that.
Author of “Elegant Objects” book gives award to projects that match his type of good OOP https://www.yegor256.com/award.html
Oh, wow. This is great! Thanks a lot!
I might buy the book, but do I get it right that it’s two volumes, each $40? Worth it?
Edit: Oh well, I ordered the first one and will see how it goes.
OMG, @nbardiuk this is so great! Thank you so much! Well worth the $40. I’m on page 35 and I can already see that this is the most idiotic and ridiculous book about OOP I’ve ever read. Expect a fun blog posts as soon as I finish!
This matches my experience working with Clojure REPL that provides fast feedback on running application. I can quickly check how the changed code works similarly to small test. Small iterations are more important than sequence when tests are written.
This is important point. In my experience TDD codebases have better tests and more maintainable production code. TDD is a good process to learn how to write testable code.
For most of languages I use LSP. The main advantage is that it understands the language and knows where to find definitions, find usages, perform renames, display documentation. The disadvantage is that some implementations of servers are slow, (or all of them are slow, depends on your definition of slow).
Yeah, 72 is much more reasonable. We need hard limits, or at least ‘annnoying’ conventions to keep the horrors at bay. The human eye scans lines best at around 72 characters wide, and we should put human readability of our code before other concerns. I have worked on projects that had huge long lines and there is no excuse. If a language or tool or whatever can’t deal with human limits, find or make another tool. Linus’ current workstation should not be the standard.
That being said, I think Racket has made a reasonable compromise:
https://docs.racket-lang.org/style/Textual_Matters.html
I would like to have 72 chars wide line but with ignored indentation. It would make nested block readable on its own.
Example with 40 chars width ignoring indentation white space
Versus 40 chars width including indentation
With monospace fonts? Or proportional ones? With large text or small?
With English prose, poetry, or with C code? With hyphenation? Indentation?
I’ve found that recommendation is pretty good for English text with a middle size proportional font. I do not find it works as well for code.
100% agreed. As I argued in the comments above, people don’t read code the same way that they read prose, and so I would not try to generalize a heuristic meant for prose to code.
I agree. Reading written text involves repeatedly shifting your focus to the line below. A consistent and short line length in that case is very important. Code is not the same. It’s far more common reading code to study a single line or small block, and in that case, I find that arbitrarily wrapping a line to stay within 80 characters usually breaks consistency and harms readability. I used to subscribe to the 80 character limit until I realised this difference. We don’t read code like we read written text.
Terminal/editor windows side by side is a fine point, but in general the vast majority of lines of code are short anyway, often well under 80 characters. If a few lines happen to wrap on your display, I hardly think that’s going to completely kill readability, and it’s certainly a trade-off I’m willing to make. If many lines are wrapping then yes, you probably have a problem with your code formatting (or your code in general). It’s the hard limit that I take issue with. Back when I wrote my own code like this, all too often I would find myself renaming identifiers (usually for the worse) among other arbitrary and unhelpful things, just to fit some code within a line without wrapping. I wouldn’t be surprised if more often than not this is the outcome for many others who attempt this, and it’s almost certainly a net negative for readability. Dropping the idea entirely has been a huge relief. One less thing to think about. Most of my code still consists of short lines, as it always did, and as most code naturally does. But when I need to, and it makes sense to write a longer line, I don’t spend a second agonising over whether it fits within some special number of characters, and instead focus entirely on whether it in itself is clear and understandable.
I want to reinforce your comment that
Recently, I have been trying to optimise my on-screen experience and I found a series of peer-reviewed articles with recommendations that improved my experience.
In one of those, it is claimed, indeed, that more than 72 and less than 80 characters (precisely, 77) is the optimal number for clear readability.
The study is for dyslexic people, and I was never diagnosed as so. But it works for me, and I tend to believe it works for most people as well.
Yeah what I’ve read confirms this, I think the width of the text column can vary based on the character width. For example in CSS I typically set something like:
You can also use
72chto set it based on width of the 0 character (which will approximate it)NixOS on my personal laptop and MacOS + Nix at work.