Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

developer.apple.com

Post reply on HN
Print view View original

391–400 of 450 posts

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

#391

Post by goalieca »

bnt wrote: post #215
oarsinsync wrote: post #195

Earlier quoted context omitted.

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

Funny. I learned on qbasic and I remember they were teaching dr racket at ubc to first year students. They were teaching java when I was in engineering and my career has basically gotten zero Mileage from that stinking heap of uncollected garbage.

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

#392

Post by eropple »

saagarjha wrote: post #151
m463 wrote: post #77

Earlier quoted context omitted.

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…

> apple doesn't want macos to be virtualized. The macOS EULA explicitly allows macOS to be virtualized if you do it on a Mac running macOS. > It would be really nice to have say the current xcode in one container and a dev xcode in another. This is the entire point behind xcode-select. I currently have Xcode-beta and Xcode on side-by-side on my machine, and they pretty much coexist.

Can you run them simultaneously? I've never tried.

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

#393

Post by ken »

Gaelan wrote: post #132
ken wrote: 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…

I think you’re overthinking this. The vast majority of Ruby/Python programmers have been installing their own copies themselves, because Apple was pretty slow in updating them (Ruby is usually a few minor releases behind, Python is still 2.7 IIRC). People will just keep doing that, and nothing will change. They may or may not be moving off Unix, but this isn’t evidence of that.

This alone isn't evidence of that, but it's not the only data point we have. We've got 20 years of observations. They dropped X11 (and didn't use it for the main display in the first place), created new process APIs (like GCD and background tasks), deprecated standard libraries like OpenGL (and don't support Vulkan), designed their own programming language, etc. All of these point in the same direction.

What will be left? Will it still be "Unix" in any meaningful sense just for having a C compiler and running an old version of Bash? Microsoft Windows did that, too.

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

#394

Post by jzl »

wtallis wrote: post #331
jzl wrote: post #220

Earlier quoted context omitted.

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

I suspect they plan to distribute the scripting languages the same way they currently handle the command line developer tools package, where the OS offers to download and install the package the first time you try to run one of those tools.

I just don't see the win of that over supplying the thing with the OS in the first place, unless the commands to do it are a nascent versioned ecosystem along the lines of brew, apt, etc.. It seems like the whole point of not supplying them with the OS is to make the versions less tied down. If there's some opaque command to get an arbitrary version, that's not going to help anyone.

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

#395

Post by e12e »

JohnBooty wrote: post #104
ken wrote: 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…

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. Ruby on Windows is a nightmare. 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 ve…

> Ruby on Windows is a nightmare.

Nightmare? No. Suboptimal? Yes.

We're running some legacy rails 3.2 against oracle db on windows, and it works well enough. It sure is a lot more pleasant on linux, though.

Biggest challenge on windows is to get a c compiler working/get binary dependencies working. Other than that, you need a version manager (same for other platforms really, unless you're aiming to shoot yourself in the foot).

Ruby on windows is definitely not great, but "nightmare" is a bit much.

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

#396

Post by e12e »

YeGoblynQueenne wrote: post #329
ken wrote: 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…

>> (As RMS wrote in 1983, "Unix is not my ideal system, but it is not too bad. The essential features of Unix seem to be good ones, and I think I can fill in what Unix lacks without spoiling them. And a system compatible with Unix would be convenient for many other people to adopt.") I have a historical question and I wonder if anyone in this thread has the answer: why did RMS (and, presumably, by then his cycle) had…

In addition to sibling comments, remember that Linus announced Linux as:

"Hello everybody out there using minix -

I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones. (...)"

GNU couldn't use MINIX due to the license (unlike minix 3), and as I recall, the bsd's were also in somewhat unclear license terms.

Gnu made the libc, compiler and various userland tools - but no-one did a" simple get it working"-kind of kernel, and then Linux came along.

I suppose part of this might be because in early gnu days, most gnu hackers used university Unix machines - not personal 80x86 for development.

If you bough sun hw you got Solaris. Only if you bought a pc clone would you be wanting a "real" os...

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

#397

Post by olliej »

jdsully wrote: post #256
olliej wrote: post #112

Earlier quoted context omitted.

The problem is that updating to a new version isn’t possible if it breaks existing software - what happens is that the end user experience is “I installed these updates and Apple broke my program” so don't update in future, and tell others not to as well. The only way to stop the OS from including out of date software and libraries is to not ship them if they don’t have stable abi. That’s what Apple is doing: it can’…

Doesn’t removing them have the same issue? “My software dependent on this ancient python no longer works - because there’s no python anymore”

Yes, the difference is that now Apple is shipping a new version that will have the same problem in a years time, so instead of one compatibility event there’s a new one.

The app developer also now has a problem - their binary only works on one OS revision so they have to start shipping the same code, just compiled separately. The only safe solution is to ship with their own embedded version. Which is also the correct solution to the interpreters not being part of the platform.

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

#398

Post by olliej »

saagarjha wrote: post #349
olliej wrote: post #216

Earlier quoted context omitted.

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

> struct layouts and sizes To be fair, this is less an an issue with non-fragile ivars in Objective-C.

Yup but OSX has a tonne of C (and unfortunately C++) APIs.

But yeah having most of the system apis being in a language that has built in dynamic resolution makes a world of difference in the difficulty of maintaining abi compat

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

#399

Post by TimTheTinker »

em500 wrote: post #311
kccqzy wrote: post #233

Earlier quoted context omitted.

The young, bored but smart kid in an elementary or middle school tinkering with her computer and finding something to do. She doesn't need a book or a tutorial to tell her the "right" way. She experiments, only guided by her curiosity.

There still Swift Playground, Safari JS console, not to mention old fashioned zsh/bash/ksh to tinker with. The part where the removal of the default macOS Python/Ruby/perl (which don't even have autocompletion) kills her curiosity seems far fetched.

What command-line programming language interpreters are left when those are removed? You have the shell itself, but that’s hardly enough to write anything cool.

This feels the same as when Microsoft removed QBasic from Windows 98. So many kids at home missed opportunities to be exposed to programming from them on, until a certain Terminal application appeared in Mac OS X and began to pique young curiosity again (mine included).

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

#400

Post by JohnBooty »

e12e wrote: post #395
JohnBooty wrote: post #104

Earlier quoted context omitted.

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. Ruby on Windows is a nightmare. 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 ve…

> Ruby on Windows is a nightmare. Nightmare? No. Suboptimal? Yes. We're running some legacy rails 3.2 against oracle db on windows, and it works well enough. It sure is a lot more pleasant on linux, though. Biggest challenge on windows is to get a c compiler working/get binary dependencies working. Other than that, you need a version manager (same for other platforms really, unless you're aiming to shoot yourself in…

We probably agree on an objective level. I would agree with you that nearly all of it works nearly all of the time.

But that's my idea of a nightmare - when things are suboptimal and you're often scrambling for solutions on a second-class platform. When I say "often" I don't mean "every day", but in my experience it happened enough to make me swear off Rails on Windows forever.

Of course maybe 5.x is different. My experience was in the late 3.x and early 4.x days

Post reply on HN