71–80 of 203 posts
Many of the Vim nerds I know, including myself, have switched over to Neovim. Only when using a remote server with a default installation do I use regular old Vim.
Neovim turned itself into a pop-blink IDE which some people never wanted. It's good that it serves the needs of its fans, but it's also good that Vim stayed in its own tracks. Losing Vim as it is would be a great loss for many.
Earlier quoted context omitted.
https://survey.stackoverflow.co/2024/technology#1-other-tool... emacs is 4% vs VSCode 73%, so it's not popular, though vim still is
Thanks. In more detail: Visual Studio Code 73.6% Visual Studio 29.3% IntelliJ IDEA 26.8% Notepad++ 23.9% Vim 21.6% Android Studio 16.1% PyCharm 15.1% Jupyter Notebook/JupyterLab 12.8% Neovim 12.5% ... Emacs 4.2% ... Spacemacs 0.4% So Vim + Neovim = 34.1%, essentially second to Visual Studio, the overwhelming leader.
Many of the Vim nerds I know, including myself, have switched over to Neovim. Only when using a remote server with a default installation do I use regular old Vim.
Earlier quoted context omitted.
I have tried several times and I always switched back to vanilla vim. Neovim has various nice features but it requires a lot of time to migrate correctly IMHO. 20 years of habits are hard to leave, I think. Sure the configuration file is retro compatible, but some of the plugins are better suited for neovim and vice versa. I use a dozen of them and if I switch permanently to neovim I'd like to start fresh using more…
When I migrated years ago (mostly to get access to some plugins), nvim gladly swallowed my old configuration with no changes. Then I could change to lua and other modern features at my own pace.
Earlier quoted context omitted.
Neovim turned itself into a pop-blink IDE which some people never wanted. It's good that it serves the needs of its fans, but it's also good that Vim stayed in its own tracks. Losing Vim as it is would be a great loss for many.
What does 'pop-blink' mean in this context?
Earlier quoted context omitted.
If Vim tracks you then that’s a willfull act that breaches trust. IMO no governance model can defend against supply chain attacks. IMO you shouldn’t try to fix things with governance model which it doesn’t fix. Use a governance model that leads to good governance. In technical and creative work single highest point of authority is best. Not because they have perfect knowledge or are the best but because dictator led…
Hmh, I don't have a case study at hand, but there are many reports (and management self-help literature) where teams are shown to be the superior approach to complex situations, especially in software development. Furthermore, considering that there are only about 50 identified open source projects out there with a BDFL [1] and only a few of them are clearly best-of-breed, while there are many best-of-breed projects…
Isn’t the manager himself the BDFL - or a part of a BDFL led chain of command - for the team he is empowering in this case?
He does not give out the organizational governance-authority just by empowering the team.
Having a BDFL does not imply micromanagement or not empowering teams. It’a a different granularity role than implementing day-to-day issues.
There are people who are really talented leaders. The problem are bad leaders - not the governance model IMO. And this is not a “no true scotsman” argument since effective leadership is a documented and observable phenomenon.
Lack of authority is probably better than poor leadership but not better than good leadership (e.g. legendary John Kelly of Skunkworks fame for an fairly well documented example).
Earlier quoted context omitted.
Hmh, I don't have a case study at hand, but there are many reports (and management self-help literature) where teams are shown to be the superior approach to complex situations, especially in software development. Furthermore, considering that there are only about 50 identified open source projects out there with a BDFL [1] and only a few of them are clearly best-of-breed, while there are many best-of-breed projects…
Any tiny project on Github, Gitlab, ... which is maintained by one person but accepts PRs and feedback from outside contributors is essentially a BDFL project. The single project owner decides what goes and doesn't go into the project by merging or rejecting PRs. People are still free to maintain their own forks with contributions that are not accepted into the main version. In a way, the entire Github workflow is bu…
It’s an accurate observation that single contributor projects work well since then there is no need to spend effort in coordination and communication.
Many of the Vim nerds I know, including myself, have switched over to Neovim. Only when using a remote server with a default installation do I use regular old Vim.
Neovim turned itself into a pop-blink IDE which some people never wanted. It's good that it serves the needs of its fans, but it's also good that Vim stayed in its own tracks. Losing Vim as it is would be a great loss for many.
I also think that "stability" and the "community" are two other things that made me switch back to vim.
Earlier quoted context omitted.
What does 'pop-blink' mean in this context?
Something pops out and blinks on itself while you are typing. At least that's what I've seen in neovim "ads" videos back in the day.
Earlier quoted context omitted.
Any tiny project on Github, Gitlab, ... which is maintained by one person but accepts PRs and feedback from outside contributors is essentially a BDFL project. The single project owner decides what goes and doesn't go into the project by merging or rejecting PRs. People are still free to maintain their own forks with contributions that are not accepted into the main version. In a way, the entire Github workflow is bu…
IMHO - No - having individual contributor workflows is diffenrent thing than aligning 10 people. The question is not who gets to do the decisions but how the team aligns itself and coordinates. It’s an accurate observation that single contributor projects work well since then there is no need to spend effort in coordination and communication.
...IMHO it's the other way around, somebody needs to do the difficult and unpopular decisions exactly for those hopefully rare situations where the self-coordination within a team fails (and doing that in a way that doesn't piss off people in the team). In the end, contributors to an open source project are also just a very loosely coupled team.
'Unpopular' decisions are much easier to do in projects that have a universally accepted and respected BDFL (ideally the project founder) than in most 'commercial' teams led by random 'management-caste' peeps.