macOS and scripting

Apple to Deprecate Scripting Languages in Future Versions of macOS - TidBITS

Apple says future versions of macOS won’t include a number of open-source scripting languages. The impact of this change will vary depending on the audience, but it will affect more people than you might think.

My visceral reaction was “WTF!! What the bloody f**k”. When I calm down, I’ll hopefully post a more reasoned response. For now, I’ll include some links and some quotes from around the web.

Before removing these scripting languages from macOS, Apple will need to address its own reliance on them. Xcode includes many libraries in all three of the mentioned languages, but it should be trivial for Apple to add the runtimes to Xcode’s already enormous install. iMovie includes a lone Perl script, and it wouldn’t surprise me if Apple’s pro apps like Final Cut Pro X and Logic Pro X also contain some.

In addition to Apple’s apps, macOS 10.14 Mojave contains over 175 scripts outside the folders devoted to Perl, Python, and Ruby. Some are a part of the language, just in a different place, but the rest serve varied purposes. Once I realized how many there were, it seemed much less likely that all three languages would be removed in the macOS version after Catalina. Curtis Wilcox

Could removing scripting languages from macOS hinder others from being interested in and learning to programme?

Are we going to ask that person to figure out how to install Ruby? If there are one-click installers out there, are we going to ask them to figure out which one is actually reputable and safe?

Curiosity like this is one of the ways new developers are made. I worry that the less the Mac is tinkerable out-of-the-box, the fewer developers we’ll get.

Or: we’ll only get certain kinds of developers — the ones of the right age and background who can go get a CS degree.Brent Simmons

Why is Apple making this change? Is this because Apple doesn’t like the restriction in the open-source GNU Public licenses compared to the MIT license? Is it because Apple sucks at security?

So the question is why? I can’t wrap my head around any real benefit to Apple’s line of reasoning on this. They’ve not been great about keeping the runtimes up to date, but that’s actually been a boon, requiring less effort to keep scripts working with every OS release. These runtimes were even touted as a selling point in the past, and Microsoft is just now starting to add tools like this to the default Windows install. And they’re including a sexy Terminal. So why is Apple moving in the opposite direction?

My only guess is that it’s directly related to the iOS-ification of macOS. iOS is based on Unix, just like macOS, but scripting runtimes have never been included (nor are they installable without bundling). So, security? A higher wall on the garden, one more easily controlled? It can’t be about file size, nor complexity for the everyday user. It doesn’t affect either in any measurable way. I don’t have an answer to this question yet, and I don’t know that we’ll ever really get one.Brett Terpstra

UPDATE: I have had some time to consider this for a cyber-security perspective. Apple's decision to remove deprecated versions of scripting language and other *NIX tools will make macOS more secure. Users who need these tools can install them. It's part of the learning for the system. If a user is curious and confident enough to launch Terminal and poke around the macOS system, that user can figure out how to install Homebrew.

Programming Languages

I was chatting with a friend about forgotten programming languages and how many we had learned and forgotten. During a quick Google search for "hundreds of frameworks and languages," I stumbled upon this intriguing list of computer programming languages. The way Bradley broke his list into categories caught my attention, and I couldn’t help but feel nostalgic.

Over the years, I've encountered and dabbled with several languages. I coded in Commodore BASIC, Pascal, and Motorola 68xx assembly language in high school and university. Later, I extensively used C, Perl, PHP, and JavaScript during my professional journey.

While I did learn languages like C++, Java, Objective-C, and Python, I must admit that I haven't had the chance to create anything meaningful with them. And thanks to my Linux and web development background, I can claim to know scripting languages like Awk and Tcl, along with markup languages such as HTML, XML, and XHTML. It's a pretty diverse list, to say the least!

Though I might have forgotten how to use some of these languages due to lack of practice, I could quickly brush up on my Perl, PHP, and JavaScript skills for web development and systems management if a project came my way. Of all the languages I've encountered, Perl has always held a special place in my heart. It allowed me to express myself freely without enforcing rigid computer science rules. As they say in the programming community, "there is more than one way to do it" with Perl, and I love its philosophy, as highlighted in the book Learning Perl "Making Easy Things Easy and Hard Things Possible."

Looking back at this diverse list of languages, I can't help but marvel at the incredible journey I've had with programming. Each language brought its unique charm and possibilities, making my experience in the world of coding truly memorable.

Why Perl Didn't Win

Why Perl Didn't Win by Big Blue Marble LLC

With every year that passed, as Perl 6 produced more press releases than actual code, the attractiveness of Perl as a platform declined. Sure, it still had users. Sure, it still had people starting new projects. (The Modern Perl movement was a decent attempt to bring wider enthusiasm back into the ecosystem by dispelling some of the worst myths of the language. It modeled itself after JavaScript: The Good Parts without realizing that Perl lacked JavaScript's insurmountable advantage of ubiquity. Who could have predicted that Objective-C would be interesting again a year before the iPhone came out?)

 

 

What it didn't have was a clearly defined future, let alone an articulated one.