Live data from Hacker News

macOS deprecating scripting language runtimes, including Python, Ruby, and Perl

developer.apple.com

211–220 of 450 posts

Re: macOS deprecating scripting language runtimes, including Python, Ruby, and Perl

#211

Earlier quoted context omitted.

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…

I agree overall, but I do think it's a little sad that you can no longer open a Terminal and start writing Python. I think this legitimately matters in terms of increasing overall tech and programming literacy. Mind, there's still a command line and shell built-in, which I consider far more important.

You can open https://repl.it/languages/python3 and start writing Python.

Re: macOS deprecating scripting language runtimes, including Python, Ruby, and Perl

#212
post #76

Not 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…

One good thing about programming on Mac is the UNIX environment which basically works just like on Linux. Makes it great for finding questions/solutions that work (vs on Windows for example). Do you see that changing as macOS gets away from UNIX? That would probably be a bad hit on apple if Linux becomes then the de facto programming OS when Apple drops UNIX

What makes you think Apple has any plans to move away from Unix?

Re: macOS deprecating scripting language runtimes, including Python, Ruby, and Perl

#213
post #76

Not 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…

Ruby/Python/Perl is not UNIX.

Re: macOS deprecating scripting language runtimes, including Python, Ruby, and Perl

#214
post #210

Earlier quoted context omitted.

paths, compilation etc. Windows isn't main server platform, so people seems like just don't care.

You can use / on Windows in node perfectly, and Windows node now installs required devtools for native modules at the end of the process. It's pretty easy these days.

You can use it, yep, but devtools aren't enough. You'll meet a lot of issues sooner or later. Windows is second-class citizen for Node, Linux or macOS are much better - just share my experience.

Re: macOS deprecating scripting language runtimes, including Python, Ruby, and Perl

#215

Earlier quoted context omitted.

As a counter-anecdote, the built in Ruby interpreter in Mac OS X Tiger was the way I learned to program and how I got interested in programming. I don't think a bare Ruby interpreter is the best way to get into programming, but Apple hasn't been great at encouraging programming among kids. As a kid, its development tools were totally baffling, where Ruby was much easier to understand.

> Apple hasn't been great at encouraging programming among kids You should check out what they’ve been doing for years with Swift Playgrounds on the iPad

But that's teaching a new generation of coders a set of tools designed only for Apple. Ruby (Python etc) are open and easily available on other platforms, Swift may be in the future but it isn't now.

Re: macOS deprecating scripting language runtimes, including Python, Ruby, and Perl

#216
post #7

Probably 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…

It’s part of why companies like Apple and Microsoft care so much about backwards compat Compared to (former) Microsoft, I don't think Apple spends anywhere near the amount of effort MS does on backwards compatibility. You can create a single .exe that will work on any Windows starting from Windows 95 - nearly 25 years. In that timespan, Apple changed CPU architectures twice, and their OS architecture once. If you're…

That's simply wrong.

Apple maintained 68k compatibility for years after it migrated to ppc. That's a completely different hardware architecture

It maintained classic compatibility for years after it moved to osx. That's a completely different kernel and basic system architecture.

It maintained PPC compatibility for a few years after transitioning to intel.

It supported 32 bit x86 for a number of years after the entire line was 64 bit capable.

Apple does care about compatibility, it just isn't as beholden to the past: it's much more willing to say "this is bad, so we're deprecating it, eventually it won't exist/work".

But they work to not break any software until the feature being used is actually removed.

It is considered a high priority bug if someone changes behaviour of a function or object in a way that isn't backwards compatible. All APIs are essentially statically vetted to ensure they don't change, including things like struct layouts and sizes.

That said, it kind of misses the point to respond to "Apple and MS care about backwards compatibility" in this context to say " I don't think Apple spends anywhere near the amount of effort MS does on backwards compatibility". The point is that if you care at all then libraries and services that are unwilling (or even hostile to) abi stability cannot viably be shipped in any publicly facing way as part of your platform.

Re: macOS deprecating scripting language runtimes, including Python, Ruby, and Perl

#217

Earlier quoted context omitted.

As a counter-anecdote, the built in Ruby interpreter in Mac OS X Tiger was the way I learned to program and how I got interested in programming. I don't think a bare Ruby interpreter is the best way to get into programming, but Apple hasn't been great at encouraging programming among kids. As a kid, its development tools were totally baffling, where Ruby was much easier to understand.

Swift Playground for macOS? One can hope!

Technically Xcode has supported Playgrounds since before the iOS app existed, though if you mean the teaching content, it doesn't have that.

Re: macOS deprecating scripting language runtimes, including Python, Ruby, and Perl

#218

Earlier 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.

It's honestly terrible for newbies. If they try to use it, there's no pip included. So then they easy_install all their libraries which installs things into different places than most python devs will be used to. Or they easy_install pip first. But even still, everything is installing to system paths, so when they try to install things it fails with permission errors. They find a stack overflow post that says just "s…

So you're saying Apple should adopt brew as default package manager and install all system tools using brew? I could get behind that, but just dropping everything without replacement makes it harder for first-time programmers.

Re: macOS deprecating scripting language runtimes, including Python, Ruby, and Perl

#219

Earlier quoted context omitted.

I'd think a script that you pipe into a shell with admin privileges is more likely ;)

Same difference, really.

No: you can sign and notarize packages.

Re: macOS deprecating scripting language runtimes, including Python, Ruby, and Perl

#220
post #136
post #125

I'm trying to understand how these two points reconcile. "Future versions of macOS won’t include scripting language runtimes by default" and "Use of Python 2.7 isn’t recommended as this version is included in macOS for compatibility with legacy software. Future versions of macOS won’t include Python 2.7. Instead, it’s recommended that you run python3 from within Terminal." If Catalina is the last version with any scr…

As I understood it, scripting languages will still be available to the user, they just won’t have ancient versions preinstalled. Of course that also means you can’t rely on them being installed at all as a developer. Which means you should start bundling the stuff you need to run your app, and, they’d like you not to use the same ancient batteries as they have previously made available, because, well they are ancient…

Ok, I guess it's worded vaguely enough to allow for the possibility of optional installation ("by default"), even though they don't outright promise that they'll offer a way to install it. (I interpreted it in the same way as "macOS doesn't include Photoshop by default".) Having it come from the app store doesn't seem totally appropriate since it would need to do more than dump a bundle into /Applications, like making some /usr/local/bin symlinks. Maybe they'll allow themselves that exception.

"they’d like you not to use the same ancient batteries as they have previously made available, because, well they are ancient" --> Right, I couldn't figure out if that's all they meant. Valid point or not, it doesn't seem appropriate to make it in the context of those notes. If you're going to make me bundle the language anyway, don't also give me a lecture about which version to use. :)

Post reply on HN