3 ms·

I didn't say "native Windows", I said cross-platform. The kind where the tooling you use works on every OS. Cross platform is literally the opposite of "anythin

I didn't say "native Windows", I said cross-platform. The kind where the tooling you use works on every OS. Cross platform is literally the opposite of "anything-native": you workflows and tooling are OS-agnostic, even if the end results are binaries specific to all major OSses (and of course, a lot of dev work never involves generating binaries)

theamk 2y ago
Sorry, I was not clear: by "native Windows", I meant the Window-specific tooling (batch files, powershell, registry etc...). This is a whole separate world in the opposition to *nix (which today means Linux, BSDs and Max OS) which use things like bash, coreutils, and so on. My point that now, in 2024, there is really no need to bother with both Windows and *nix support, unless you have special requirements. "Cross platform including non-WSL Windows support" is much more complex and limited than "cross platform which requires WSL on windows", and no one should waste their resources on that without a very good reason. It's perfectly fine to require *nix-like OS for your workflows and enjoy the ease and compatibility that this brings to the table. This is especially important for open-source contributors, too: someone running Mac OS or Linux is going to be heavily discouraged from contributing any scripts if all scripts are required to be Windows-compatible. And someone running Windows might contribute powershell script but that would be useless for non-Windows people, limiting its utility. My advice to everyone is: unless your app is in Windows-heavy niche, drop non-WSL windows support requirement.
- TheRealPomax 2y ago
  I also didn't say "windows specific tooling". A modern code editor or IDE already covers 80%, if not more, of what the article's tools cover. You don't need separate applications for the things that article explains as use-cases. And by not using or advocating unix-specific command line utilities, you solve two problems: people don't need to learn commands they don't want to learn, and the tools that you do use tend to be cross-platform by default. Anyone on Windows, Linux, MacOS, FreeBSD, etc can use those same tools. Telling a contributor "we recommend using VS Code with these extensions" in 2024 is pretty much the lowest barrier to entry you could ask for. Whether your build tooling requires platform-specific tools is a completely different issue: this article and my comment on it isn't about that context. They're about commands that the article claims are essential to you, a person, in order to be a better developer. And to that statement my response is: you really don't. These can certainly be useful to know, but they're also completely optional.

theamk 2y ago

Sorry, I was not clear: by "native Windows", I meant the Window-specific tooling (batch files, powershell, registry etc...). This is a whole separate world in the opposition to *nix (which today means Linux, BSDs and Max OS) which use things like bash, coreutils, and so on. My point that now, in 2024, there is really no need to bother with both Windows and *nix support, unless you have special requirements. "Cross platform including non-WSL Windows support" is much more complex and limited than "cross platform which requires WSL on windows", and no one should waste their resources on that without a very good reason. It's perfectly fine to require *nix-like OS for your workflows and enjoy the ease and compatibility that this brings to the table. This is especially important for open-source contributors, too: someone running Mac OS or Linux is going to be heavily discouraged from contributing any scripts if all scripts are required to be Windows-compatible. And someone running Windows might contribute powershell script but that would be useless for non-Windows people, limiting its utility. My advice to everyone is: unless your app is in Windows-heavy niche, drop non-WSL windows support requirement.

TheRealPomax 2y ago
I also didn't say "windows specific tooling". A modern code editor or IDE already covers 80%, if not more, of what the article's tools cover. You don't need separate applications for the things that article explains as use-cases. And by not using or advocating unix-specific command line utilities, you solve two problems: people don't need to learn commands they don't want to learn, and the tools that you do use tend to be cross-platform by default. Anyone on Windows, Linux, MacOS, FreeBSD, etc can use those same tools. Telling a contributor "we recommend using VS Code with these extensions" in 2024 is pretty much the lowest barrier to entry you could ask for. Whether your build tooling requires platform-specific tools is a completely different issue: this article and my comment on it isn't about that context. They're about commands that the article claims are essential to you, a person, in order to be a better developer. And to that statement my response is: you really don't. These can certainly be useful to know, but they're also completely optional.