[jackson1442]

> I have no idea to this day how macs became the premier development environment.

I've been editing a tutorial one of my coworkers wrote that targets new Python users on Windows. From my findings, the grass is not greener.

Granted, geospatial Python is somewhat of a mess, but a lot of tools I have to use are somewhat messy forks of Unix tools (looking at you, pyenv-win) with tons of incompatible extensions. For development, Windows is the exception because you can transfer just about anything from Linux to macOS.

On my Mac, I can easily install all of the Python packages I need without needing to install Visual Studio, pipwin, anaconda, etc. I have bash/zsh as my default system shell. Maybe it's easier to native Windows users, but bash/brew is a much better combination than anything I've found in Windows.

WSL is a step in the right direction, but it still feels secondary. If a first-class terminal experience existed on Windows, I have a strong feeling that it could be the premier development environment, or at least closer to Mac.

Maybe I'm using it wrong, but it definitely hasn't been made clear on how to use it right.

[sangnoir]

> I've been editing a tutorial one of my coworkers wrote that targets new Python users on Windows. From my findings, the grass is not greener.

Maybe check the other other side (Linux) - I found the grass is greener there - at least for Python (and programming tools in general). I'm very comfortable on the command-line, and moving from a pure Linux environment to OS X & brew felt like a huge downgrade, followed by random annoyances that remind you you are using inferior, non-GNU utilities:

  $ ls my_dir -l
  ls: -l: No such directory

Really - Mac OS? I know its minor, but that's just user-hostile and it happens every few weeks; I can't get over it.

[coldtea]

>followed by random annoyances that remind you you are using inferior, non-GNU utilities:

Well, you can switch to another ls in 10 seconds by "brew install gnutools" or some such.

Not to mention the same arguments could be made for FreeBSD, commercial unices, etc.

Come to think of it, I've been using Unix (including Linux) for 25 years, and never even occured to me to expect "ls my_dir -l" to work.

[mkl]

What do you do if you want to add extra arguments when your cursor's at the end? Navigate back near (not to) the beginning? I usually just put them at the end, as almost every program I've used supports it. I add extra arguments after running commands constantly; after pressing up to get it back, you're at the end.

[coldtea]

>What do you do if you want to add extra arguments when your cursor's at the end? Navigate back near (not to) the beginning?

Yes. In most shells it's trivial to go back by a word (e.g. skip in front of the path with one shortcut).

That said, this happens so rare that it's not even something that ever registered with me as a problem. I know what arguments I want for ls. And if I don't it's usually some bizarro infrequent flag that I have to look up how it's used anyway.

And other programs where it would be actually useful don't allow it anyway (having flags after the "main" argument). Git, for one.

[sangnoir]

> Well, you can switch to another ls in 10 seconds by "brew install gnutools" or some such.

I did - but I never remember to type "gls" instead of "ls" - if I were that mindful, I'd always put in the flags at the start, where the BSD utils expect them. As sibling comment noted, trailing flags usually happens when I run a command and decide to amend the flags by up-arrowing and typing. A typical result is "ls -al my_dir -tr" when I realize I want to sort by mod date, post-facto.

I've been using GNU utils 95% of the time I've used Unix(-like) systems: I expect "ls -al my_dir -tr" to work: it's 2021 - recognizing flags isn't rocket science.

[analog31]

>>>> I've been editing a tutorial one of my coworkers wrote that targets new Python users on Windows. From my findings, the grass is not greener.

I've been using WinPython for a few years. It's the closest thing to "just works" that I've found, and non-programming colleagues have been able to install it successfully.

Because it works almost like an isolated "container," it's also possible to test your code on a clean install of WinPython to make sure it will run on someone else's computer before you share it.

I don't know the technical difference between WinPython and a true container, but you can have multiple WinPython installs on one machine, and they don't interfere with one another, or with a pre-existing mainstream Python installation on the same PC. So you can share your stuff without worrying about screwing up someone else's stuff.

[jackson1442]

Good to know, thank you!