3 ms·

On the other hand, I see quite a few projects challenging The Way Things Are Done (Rust, NeoVim, Fish, OilShell, etc) to which there is a lot of kicking and scr

On the other hand, I see quite a few projects challenging The Way Things Are Done (Rust, NeoVim, Fish, OilShell, etc) to which there is a lot of kicking and screaming that things are fine. No need to change.

dylan604 4y ago
Both can be true at the same time.
- 2h 4y ago
  but not in the case. Things are not fine. I tried for years to bend over backward so that my code was POSIX compliant. At some point enough is enough.
  - mort96 4y ago
    You don't have to do that. If you're writing against Linux specifically, and your use case could make great use of Linux-specific features, use them! I've certainly done that in the past. But I've also written a whole lot of software which really couldn't care less about the OS. It needs some way to list directories, some way to read and write files, maybe some way to communicate over the network, but everything interesting happens in code that's not related to interacting with the OS. In those cases, I love that I can just write against one API and know that, if it doesn't already just work on all posixy systems, it's at least going to be easy to port.
    - jen20 4y ago
      And this is why so many new tools are written in Go.
hhmc 4y ago
Even if neovim never gathers critical mass, it must be considered a success purely for how much of a fire it has lit under vim development.
- deafpolygon 4y ago
  One would argue that it's time to build something new. Just look at the massive popularity of VS Code - people clearly want the modularity and power of Vim but none of the cruft or baggage.
Alupis 4y ago
> I see quite a few projects challenging The Way Things Are Done (Rust, NeoVim, Fish, OilShell, etc) to which there is a lot of kicking and screaming that things are fine. What you often see are half-baked, trivial re-implementations of some parts of existing utilities and then the proclamation "Rust is here and it's so much better!". A program that amounts to some undergrad's semester project isn't going to be taken seriously - and they often are not. The existing utilities are decades old, are very good at what they do, and rarely are the cause of the supposed bugs we're trying to avoid. Shell replacements, such as OilShell, can gain traction on their own, because a shell is mostly system agnostic. The struggle here is reaching critical mass of users, while also supporting all of the millions of existing shell scripts out there in the wild. No one is going to make your new wiz-bang shell the system default on a popular distro without it being completely compatible with existing shell scripts, documentation, examples, etc. It's just a non-starter...
- 3np 4y ago
  > No one is going to make your new wiz-bang shell the system default on a popular distro without it being completely compatible with existing shell scripts, documentation, examples, etc. It's just a non-starter... False. zsh is not POSIX nor fully compatible with bash, while being default login shell in popular distros like Kali and Deepin (and macOS). Not sure if Garuda Linux passes the "popular" threshold for you but their default is fish. Shell scripts typically lead with a shebang, making your login shell inconsequential as long as you have the target shell available.
  - Alupis 4y ago
    > False. zsh is not POSIX nor fully compatible with bash, while being default login shell in popular distros like Kali and Deepin (and macOS). Kali is a purpose-built distro that is not a daily driver for nearly anyone. Deepin is a Chinese distro, and while it may be popular to some, it is not a popular distro at large. My point remains standing. > Shell scripts typically lead with a shebang, making your login shell inconsequential as long as you have the target shell available. Of course - but having multiple shells installed is not common. What's the point of using another shell if all of your scripts have to use bash anyway? You are still effectively using Bash, and have unintentionally exposed the problem with all non-POSIX compliant shells - they don't allow people to get work done.
deleted 4y ago
[deleted]

dylan604 4y ago

Both can be true at the same time.

2h 4y ago
but not in the case. Things are not fine. I tried for years to bend over backward so that my code was POSIX compliant. At some point enough is enough.
- mort96 4y ago
  You don't have to do that. If you're writing against Linux specifically, and your use case could make great use of Linux-specific features, use them! I've certainly done that in the past. But I've also written a whole lot of software which really couldn't care less about the OS. It needs some way to list directories, some way to read and write files, maybe some way to communicate over the network, but everything interesting happens in code that's not related to interacting with the OS. In those cases, I love that I can just write against one API and know that, if it doesn't already just work on all posixy systems, it's at least going to be easy to port.
  - jen20 4y ago
    And this is why so many new tools are written in Go.

hhmc 4y ago

Even if neovim never gathers critical mass, it must be considered a success purely for how much of a fire it has lit under vim development.

deafpolygon 4y ago
One would argue that it's time to build something new. Just look at the massive popularity of VS Code - people clearly want the modularity and power of Vim but none of the cruft or baggage.

Alupis 4y ago

> I see quite a few projects challenging The Way Things Are Done (Rust, NeoVim, Fish, OilShell, etc) to which there is a lot of kicking and screaming that things are fine. What you often see are half-baked, trivial re-implementations of some parts of existing utilities and then the proclamation "Rust is here and it's so much better!". A program that amounts to some undergrad's semester project isn't going to be taken seriously - and they often are not. The existing utilities are decades old, are very good at what they do, and rarely are the cause of the supposed bugs we're trying to avoid. Shell replacements, such as OilShell, can gain traction on their own, because a shell is mostly system agnostic. The struggle here is reaching critical mass of users, while also supporting all of the millions of existing shell scripts out there in the wild. No one is going to make your new wiz-bang shell the system default on a popular distro without it being completely compatible with existing shell scripts, documentation, examples, etc. It's just a non-starter...

3np 4y ago
> No one is going to make your new wiz-bang shell the system default on a popular distro without it being completely compatible with existing shell scripts, documentation, examples, etc. It's just a non-starter... False. zsh is not POSIX nor fully compatible with bash, while being default login shell in popular distros like Kali and Deepin (and macOS). Not sure if Garuda Linux passes the "popular" threshold for you but their default is fish. Shell scripts typically lead with a shebang, making your login shell inconsequential as long as you have the target shell available.
- Alupis 4y ago
  > False. zsh is not POSIX nor fully compatible with bash, while being default login shell in popular distros like Kali and Deepin (and macOS). Kali is a purpose-built distro that is not a daily driver for nearly anyone. Deepin is a Chinese distro, and while it may be popular to some, it is not a popular distro at large. My point remains standing. > Shell scripts typically lead with a shebang, making your login shell inconsequential as long as you have the target shell available. Of course - but having multiple shells installed is not common. What's the point of using another shell if all of your scripts have to use bash anyway? You are still effectively using Bash, and have unintentionally exposed the problem with all non-POSIX compliant shells - they don't allow people to get work done.

deleted 4y ago

[deleted]