Civ IV will never work again. RIP.
As a huge fan of Civ IV, I've found the macOS version pretty janky. I have a generally better experience on my Mac by just using Steam In-Home Streaming from my Windows box.
macOS deprecating scripting language runtimes, including Python, Ruby, and Perl
101–110 of 450 posts
Re: macOS deprecating scripting language runtimes, including Python, Ruby, and Perl
#102Earlier quoted context omitted.
What newbie will start with Python 2.7 at this point in time? Most books and tutorials are updated for Python 3. The default Python 2.7 interpreter from macOS is useless for newbies, it does more harm than good by confusing them.
Apple could solve this problem by including python3 with macOS...
They sure could, but is it worthy to maintain an alternative package and deployment system for which you have no use yourself? Will employees be careful and committed to something useless for their jobs?
They previously deprecated Java runtime for similar reasons. And I can’t really blame them, roadmap is crystal clear now, they prefer to assign ressources to develop Swift/Swift UI and improve tooling for native code development.
Re: macOS deprecating scripting language runtimes, including Python, Ruby, and Perl
#103Probably the right call - many of them don’t have abi or api stability guarantees, or in the case of python needlessly broke backwards compatibility that is still causing pain today. Apple used to ship an incredibly old version of OpenSSL because people used its API which was not ABI stable. Even getting rid of it was a nontrivial amount of work. The lack of care about API&ABI stability in developer facing open sourc…
> The lack of care about API&ABI stability in developer facing open source projects (interpreters, libraries, frameworks, commandline arguments) is still bizarre to me: why make your work hard to use/update?
If you're a FOSS developer with limited time and man power (and if you're lucky, limited budget) maintaining backwards compatibility is hard. So hard, that new features and bug fixes might have to take a back seat to it. Also, I'm almost certain that developers would rather be implementing new features, and fixing bugs, ahead of maintaining backward compatibility. It's much easier to show a new feature or a bug fix, than it is to show how backward compatibility was maintained.
Also, the big users of FOSS, projects like Debian (and Ubuntu) and Fedora, will rebuild their entire systems when new versions of software are released/integrated. This reduces the maintainer's requirements to keep ABI compatible.
Re: macOS deprecating scripting language runtimes, including Python, Ruby, and Perl
#104Not surprising at all. It's become clear that what they've been doing with iOS all along is bootstrapping a new operating system. They started with Unix, not because Unix was optimal for what they wanted to do, but it's what they had and it worked well enough. Copland and Taligent and the rest failed because of Second-System Effect, which Apple was smart enough to avoid. (As RMS wrote in 1983, "Unix is not my ideal s…
They've got enough market clout now that people will
port Ruby/Python/Perl to a non-Unix macOS, just as
they port them to Microsoft Windows.
To be specific, Ruby itself (the core language and core libraries) are pretty good on Windows. Great choice for a scripting language, or whatever else you want to do.
But libraries like ActiveRecord, Rails and their myriad dependencies are very very hit or miss on Windows and there's not a lot of support when things go badly.
A lot of the issues are simple - like dead simple. Lot of gem authors don't bother to make things like file paths (forward slash vs. backslash) system agnostic. Or the gems depend on compiled binary stuff like Nokogiri or ImageMagick and those are always a bit of an adventure on Windows.
If MacOS drifts farther away from Unix they will cease to be the platform of choice for many developers currently using it today.
Re: macOS deprecating scripting language runtimes, including Python, Ruby, and Perl
#105Earlier quoted context omitted.
Does OSX offer reasonable container technology? chroot?
I think apple fundamentally does not understand containers. All the interesting container stuff is on other platforms. It might be out of fear, maybe because apple doesn't want macos to be virtualized. It would be really nice to have say the current xcode in one container and a dev xcode in another. It would be nice to farm work out to a lot of machines. or a dockerfile like: FROM macos:10.14 RUN installer xcode... R…
> I think apple fundamentally does not understand containers.
Given that Apple is (or at least was) one of the biggest users of Mesos in the world and have invited me to interview specifically on the back of the operationalization of containers, I'm guessing that the staggeringly bright programmers they've got probably understand containers.
Just a little hunch, you know?
Re: macOS deprecating scripting language runtimes, including Python, Ruby, and Perl
#106With brew as the de-facto package manager for macOS this is a great move. Having Python and Ruby bundled with macOS is confusing when trying to install "regular" versions of the software through brew or other methods. Because the default installation can't updated without updating the OS, the system versions are not useful for most developers.
The down side to that is that ruby is currently required to install Homebrew.
Could also just use bash to bootstrap an environment, like how RVM does.
Re: macOS deprecating scripting language runtimes, including Python, Ruby, and Perl
#107Earlier quoted context omitted.
Python and pip just being there is a huge advantage for newbies. I really think that part of programming is constantly ignored because all the decision-makers are not newbies.
Not true. It's better for them to install it themselves so they know exactly what they're using, and so they type python for python 3 and not python3.
no. it's better for newbies to learn programming rather than fight with operating systems trying to set up an environment to learn programming in
Re: macOS deprecating scripting language runtimes, including Python, Ruby, and Perl
#108Not surprising at all. It's become clear that what they've been doing with iOS all along is bootstrapping a new operating system. They started with Unix, not because Unix was optimal for what they wanted to do, but it's what they had and it worked well enough. Copland and Taligent and the rest failed because of Second-System Effect, which Apple was smart enough to avoid. (As RMS wrote in 1983, "Unix is not my ideal s…
A different solution, and possibly better, would be to run Unix/Linux in a VM rather than worrying about it being native in the system. If I'm not mistaken, current best practice is to somewhat isolate third-party developer software anyway, using homebrew, a VM or other solutions (not sure about Docker - don't use it). I can see where it would be an issue with developing for MacOS or iOS, but third-party web developm…
> A different solution, and possibly better, would be to run Unix/Linux in a VM rather than worrying about it being native in the system.
Just like WSL 2.0 (https://devblogs.microsoft.com/commandline/announcing-wsl-2/)?
Re: macOS deprecating scripting language runtimes, including Python, Ruby, and Perl
#109Earlier quoted context omitted.
Python and pip just being there is a huge advantage for newbies. I really think that part of programming is constantly ignored because all the decision-makers are not newbies.
Not true. It's better for them to install it themselves so they know exactly what they're using, and so they type python for python 3 and not python3.
I'm gonna disagree on this one. When you're just starting, the installation process can be nontrivial and the terminal window is scary. Having less friction there makes it easier to start and build some confidence. Once you have some idea of what you're doing, you can realize that you want different versions of the language.
Re: macOS deprecating scripting language runtimes, including Python, Ruby, and Perl
#110This has been a topic brought up internally at Apple many times over the past decade. Glad to see it finally moving forward. Although I see the benefits to having a system-version of these packages.. if you're doing anything serious for production then the environment should be containerized.
> if you're doing anything serious for production then the environment should be containerized.
What do you mean?