I've been using the Boldvoice app (no affiliation), it's not perfect but pretty good; my spoken English has definitely improved in a few months. I would recommend it.
> But we should look at what Lua did for Neovim. There has been an explosion of development effort now that Neovim finally added a reasonable programming interface.
It is very much debatable whether Lua is the "reasonable programming interface" causing the activity in Neovim. Vimscript has many flaws, one of them being that it doesn't look like other programming languages, but it does its specialized job pretty well. It is slow, but efforts are made in that area. Lua is well designed but it certainly has its shortcomings too, and many argue (me included) that programming in Lua is not that pleasant. The Lua bindings have been available in Vim for quite some time, but they never were popular, for some reasons.
Anyway, it is not directly related to your point, but I think that example is not that compelling.
Reading the docs and searching into it on a regular basis is the single best advice I could give to Vim users wanting to improve. The odd cheatsheet, the post with a few tricks and cool plugins, all those can be well and good, but nothing beats sitting down and reading the docs. I've been use Vim daily for 10+ years, and I still check help files very regularly. Knowing _how_ to search efficiently is also a skill worth acquiring.
Incidentally, the same advice apply to Bash: just read the man page, and search into it each time it is needed. It is just worth it.
> "If you have to write more than 10 lines, then use a real language"
I swear, there should be a HN rule against those. It pollutes every single Shell discussions, bringing nothing to them and making it hard for others do discuss the real topic.
It's a case of knowing the wooledge website (and working with shellcheck), or not. Picking snippets on stackoverflow will probably do more harm than good, tbh.
Yes, it can be cryptic and not beginner-friendly, but it's powerful and once you know it, you know it; it will be useful for years if not decades, as opposed to some tools or frameworks du jour that are sometimes as cryptic.
The main issue is that many people try (by necessity or not) to cobble scripts together without really learning the language and its idioms. It's not that hard to really learn it though, it's basically one man page then the mandatory [wooledge wiki][1].
Not OP, but I would say that we, regular Bash users, don't really write complex programs in Bash, even though it depends on what you call "complex". Some of our programs can be pretty long, and we can do more within Bash than some programmers know (eg. the arrays/associative arrays features, the vast parameter expansion options etc.), so no, we aren't bound to some 100-line-max rule, if that's what you had in mind.
Bash (and other shells) are very good at working with other programs and using the filesystem. It's true you have to know many idioms, but once you're there, you can be quite productive for these kinds of tasks.
Multiple-cursor editing is a nice and cool feature, and for what it's worth there are some vim plugins to get it in vim, but let's see the alternative:
- multiple-cursor: select non-contiguous pieces of text, then edit them all at once.
- vim macro/repeat: edit a piece of text, and repeat on similar occurrences.
The vim "way" could be, `/;$` to select the trailing semi-colon, then `cgn` to edit it (enter the curly block once in insert mode, then exit with `<Esc>`), and now you can repeat on the next trailing semi-colon simply by hitting `.` (dot).
So, instead of first looping on the occurrences to get multiple cursors, then do the editing, you first do the editing on an occurrence, and you loop on the editing. There is admittedly less of a "wow" factor, but I don't think it is any less powerful.
I also like and use tools like sed and awk; using the vim internal tools are very easy to learn if you come from there, and they have the advantage of being better suited for working with whole buffer (multilines, paragraphs etc.), instead of on a line-by-line basis.
I believe vim is a great editor for the kind of people who like sed, awk, and working from/with the shell, since it's pretty much the same culture.
Yes, if you want/need an IDE, by all means do. Vim is an editor, a very powerful one with all sorts of tools, but it's generally ill-advised to try and make it work like an IDE.
As far as I'm concerned, as a grey beard sysadmin, I don't need an IDE, so I value more the advanced editing features of Vim and I've been happy with it for years (more than I'd like to admit).
Slightly tangential, but that former stance you describe partly is a consequence of the age-old dualism between emotions and reason, to which people quite frequently subscribe despite strong evidence in the last decades from neurosciences that this is just not an adequete model--that's not how our mind work. We are not some sort of judge in their cartesian theater deliberating between the good, rational-mind and the lively but childish emotional-mind.