I think the reality is, plenty of scientists use Windows, and even among those who use Linux, many aren't that comfortable with it.
The issue is, most scientists who do software development are not used to the paradigms commonly used in Windows software development. Anything that's unfamiliar seems 'wrong' to them - and I know when I started doing dev on Windows, I felt like that too.
Just a few examples
* When making a dynamic library on Windows, you need to explicitly export the symbols you want to be visible. You can do this with GCC, but it's not the default.
* It's common to generate a .lib (import library) and a .dll for a dynamic library on Windows vs just a single .so on Linux.
* Using an IDE and MSVC projects for development is common on Windows, even with CMake support improving rapidly
* Lots of scientific packages just assume that they're running on Linux and have hard coded path names, and use tools in the setup scripts that aren't necessarily available on Windows. So Cygwin + MinGW can plug the gap sometimes, but for e.g. if you want to build a Python extension that can work via pip on Windows, that's not necessarily sufficient, because Python is usually built by MSVC and so a library you build via MinGW won't work because it's not ABI compatible.
None of these make Windows 'worse' - it's just different. And unless you know what the differences are, you do limit yourself to having a package that only works on one or the other. I used to think that knowing Linux was sufficient, but I've moved on to think that anyone calling themselves a scientific software developer should be able to (and be willing to) develop on both, even if that means pushing people to use WSL.
Also - I don't think most packages can just be taken and put on Windows CI like the author suggests. Just as a start - if it uses Make, autoconf, etc. then you're out of luck straight away and need to come up with something better.
1 comment
[ 3.0 ms ] story [ 9.6 ms ] threadThe issue is, most scientists who do software development are not used to the paradigms commonly used in Windows software development. Anything that's unfamiliar seems 'wrong' to them - and I know when I started doing dev on Windows, I felt like that too.
Just a few examples
* When making a dynamic library on Windows, you need to explicitly export the symbols you want to be visible. You can do this with GCC, but it's not the default.
* It's common to generate a .lib (import library) and a .dll for a dynamic library on Windows vs just a single .so on Linux.
* Using an IDE and MSVC projects for development is common on Windows, even with CMake support improving rapidly
* Lots of scientific packages just assume that they're running on Linux and have hard coded path names, and use tools in the setup scripts that aren't necessarily available on Windows. So Cygwin + MinGW can plug the gap sometimes, but for e.g. if you want to build a Python extension that can work via pip on Windows, that's not necessarily sufficient, because Python is usually built by MSVC and so a library you build via MinGW won't work because it's not ABI compatible.
None of these make Windows 'worse' - it's just different. And unless you know what the differences are, you do limit yourself to having a package that only works on one or the other. I used to think that knowing Linux was sufficient, but I've moved on to think that anyone calling themselves a scientific software developer should be able to (and be willing to) develop on both, even if that means pushing people to use WSL.
Also - I don't think most packages can just be taken and put on Windows CI like the author suggests. Just as a start - if it uses Make, autoconf, etc. then you're out of luck straight away and need to come up with something better.