[typomatic]

I have used Python on OSX for years and it is and always will be a horrorshow. Using the system Python installation is a nonstarter for many reasons, chief among them is that I don't have any interest in using py2. So then you're using pyenv or homebrew, but your vim install still thinks that it should be using the system python. And whoops, you fixed that and now virtualenv is not finding your interpreter. And etc., etc.

OSX and its tooling are just ridiculous. I have no idea to this day how macs became the premier development environment.

As always xkcd has a comic for it: https://xkcd.com/1987/

[coldtea]

>OSX and its tooling are just ridiculous. I have no idea to this day how macs became the premier development environment.

Because:

(a) it's quite easy to set things up with brew, macports, and/or Nix

(b) because Python is shitty everywhere anyway, and Python isn't the be-all end-all of development work.

(c) because you get a full-featured, working, coherent, take-it-or-leave-it desktop that stops one way of endless tinkering and procrastinating available in Linux to get things "just right"

(d) because it's still a UNIX with a full support for unicy tools, not a hack like WSL or WSL2.

(e) because it has good hardware (mostly - BS keyboard-era aside) and good resale value

(f) because you get to enjoy most/all the proprietary tools you like too (from MS Office and Adobe Creative Suite, to whatever)

(g) because in 2020 Docker, remote environments, etc, make many "local dev environment" points moot anyway

[ohazi]

I think it's more inertia than any of these things.

The entire point of this thread is that (a) is false -- see grandparent and the xkcd joke. It's not easy. It pretends to be easy, but is usually broken in some crazy way instead. Apt is also easy, but it actually works more often than not.

(c) was relevant in 2006, when the novelty of OS X was that it was a UNIX that you could actually use as a daily driver. This is what initially got developers to move to Mac. But it's been fifteen years, and all jokes aside, the "year of the Linux desktop" for developers was probably around 2012. Linux may still have issues, but they're not worse than the hoops you have to jump through to make today's macOS behave.

Trendy tech companies are still buying macbook pros for their employees because that's what's been trendy for the last decade, not because they actually ask new hires what they prefer. Practical tech companies do, and at places like that you usually see a mix of macs and thinkpads.

[coldtea]

>(c) was relevant in 2006, when the novelty of OS X was that it was a UNIX that you could actually use as a daily driver. This is what initially got developers to move to Mac. But it's been fifteen years, and all jokes aside, the "year of the Linux desktop" for developers was probably around 2012. Linux may still have issues, but they're not worse than the hoops you have to jump through to make today's macOS behave.

I've used Linux for close to 20+ years, and Unices more, and never had to jump through any major hoops to make macOS behave.

What would those be (talking about something major, not "I can't get my favorite window manager to replace the macOS window management" -- the non-tinkering-friendliness is part of the allure to me and from what I read others too)?

On the other hand, Linux on the desktop never fails to dissapoint me in one way or another because of the need of tinkering, half-sketched apps for many things I want to do (especially anything multimedia and/or document related), driver issues to get things working (sound, compositor, 3D, bluetooth, sleep, etc), and so on. And judging from the everpresent "just use <name of another distro>" in the relevent forums, it's not something others don't have.

Thus I prefer to stick to Linux on the server and Docker, or for setups where I have investigated the hardware in advance, and only mean to use basic things (e.g. happy with just some terminals, emacs/vim, i3, and some mp3 playing).

>not because they actually ask new hires what they prefer.

Those that do found that hires generally prefer Macs. That's how they have ~ 50% of the dev surveys on Stack Overflow whereas they're just 10% of the general market...

[ImaCake]

>was relevant in 2006, when the novelty of OS X was that it was a UNIX that you could actually use as a daily driver. This is what initially got developers to move to Mac. But it's been fifteen years

My anecdata for this is that I bought a MacBook in 2020 for precisely this reason. I am not a programmer, mostly my use case is bioinformatics and processing large datasets. Native terminal is better than WSL (although WSL is good now) and macOS is much more reliable than linux ever has been for me.

[krona]

b and g are mutually exclusive, though?

[coldtea]

Not in any logical sense (e.g. violating any Logic rule). They just cover different use cases.

(b) makes the "macOS is particularly bad for development because I found Jupyter/Python deps difficult there" argument moot, as messed up Python dependencies are the case in Windows and Linux as well.

And (g) says that Docker and co has superceded manually setting up Python environments for many (not necessarily all or even most) devs, mitigating concerns about managing multiple local versions different deps/libs/language versions to work with different projects (since you can now do that in different, isolated, virtual environments which are mini-OSes in themselves).

So (b) basically amounts to: "It's not macOS which is makes Python deps shitty, they are inherently shitty".

And (g) basically amounts to: "Since Docker and co make local development dep issues mostly obsolete, even if macOS was bad at local deps, it wouldn't matter as much today anyway as virtualization levels the field".

And of course, with the field levelled by (g), if you go for virtualized dev envrironments, you still get all the other benefits like e, f, c, and d.

[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!

[sooheon]

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

    s/macs/python
    s/development environment/scripting language