Scripting language runtimes such as Python, Ruby, and Perl are included in macOS for compatibility with legacy software. In future versions of mac...
For further actions, you may consider blocking this person and/or reporting abuse
"Scripting language" has always struck me as a weasel word. It lacks a formal definition, but is applied liberally to any language which a developer deems "not a real programming language" (whilst turning up their nose in bourgeois disgust.)
If they mean "interpreted language," that's something specific, but it would also mean dropping Java.
And...legacy? Since when is Python "legacy"? It's one of the most popular application development languages today, fer cryin' out loud. (On that note, Ruby and Perl aren't even remotely "legacy" either.)
I have a theory what's going on, though...I think Apple is just trying to "encourage" (force) developers to use their in-house languages, and build more Apple-only software. It's the whole walled-garden game again.
But then, I started boycotting Apple products four years ago, when they started explicitly blocking Linux from being able to communicate with iDevices. (And yes, tech support confirmed this.) Dirty pool is just their game.
Apple lovers: come to Linux! There's freedom on this side of the garden hedge. ;)
I agree with this sentiment. I really need to get on the Linux train.
Both Ubuntu and MATE can be customized to look like macOS, just FYI. ;-)
elementaryOS is worth a try too!
Is elementaryOS run smooth on 4Gb RAM? last i tried was version 0.2.2 so many glitch, how much RAM do you had?
Yes, elementaryOS (0.4 Loki) ran smooth on my 4GB machine.
Agreed. It really irks me when people use the term "scripting language". Even if the term is valid in the context, they're actually using it to describe a language as inferior because it's not compiled. Many of the "engineers" at my work still don't consider me their equal because I program in JavaScript and not C#, which contains the almighty compiler and static type system 😂
Wow, that's really sad to hear.
Rest assured that at least I and many others that have >15 years of experience in the industry don't value people's skills based on the language they use.
The day another vendor provides a trackpad as good as the one Apple MacBooks provide is the day I switch to Linux.
The preinstalled libraries and binaries are a tad annoying and are usually superseded by whatever Homebrew installs anyway.
On the other hand, the drivers of Linux are open source, and the quality of the trackpad is mostly determined by the software. So you're free to make it as good as you wish.
Hardwire-wise, the trackpad on puri.sm/products/librem-15/#specs seems to be to be as good
My razer's pad feels good to me (note I use a 2014 MacBookPro 60% of the time, 2018 MacBook Air 35% of the time, and the Razer 5%). But the trackpad software (or windows in general?) has issues. I feel like sliding my finger across the pad to move the mouse I end up selecting things I don't want to. I suppose that could be bad hardware but I think it's more likely bad software
Scripting language does mean interpreted. Also Java is not an interpreted language. You compile it.
I never said a scripting language is an interpreted language. The latter has a definition. The former actually doesn't.
Also, Java is indeed interpreted. It is compiled to bytecode (not machine language), which is executed by the JVM. This is why the end-user has to have the Java runtime installed on their machine.
It is technically possible (albeit uncommon) to compile Java down to machine code, but arguably, the same is true of Python.
Yeah, I as about to say the same thing. Also In theory it’s possible to compile any Interpreted language to Machine code. the different between an ”interpreted” language and a compiled language is that an interpreted language is compiled to Machine code just before execution, example being JavaScript Just in time compiler. Were as a compiled language is compiled to Machine code ahead of time.
If I wanted to I could make a A head of time compiler for JavaScript/ node.js.
I said it was. I was answering your question.
Java is not interpreted. The fact that it is compiled at all is the end of that story... But like, good talk? The jvm virtualizes a cpu. Sooooooo basically what you're saying is that if you run a c program in a virtual machine. C becomes interpreted.
Edit sorry a c Linux program on like, Windows
Edit 2 (sorry I'm drunk) in the event you're unaware. There exist[ed] processors that natively ran Java. So, what I'm talking about with c, isn't really unreasonable.
Edit 3 for funsies is assembly now interpreted in the event your writing it on a modern computer with the 8086 emulator?
By you logic Typescript must be a compiled language due to the fact you have to ‘compile’ it to JS, despite JS being an interpreted language itself. However we still consider TS to be an interpreted language.
For a language or application to be considered ‘fully’ compiled we say it must be fully compiled and shipped As Machine readable code or Machine code. This it not True for Java, which uses a intermediate language know as byte code. The Java runtime environment takes that byte code and produces Machine instructions at runtime. For the most part Java can not run on ‘Bare metal‘ systems such as embedded systems without a Java runtime environment.
Java is not a compiled language as further computation has to occur at runtime for the program’s instructions to be acted upon. Yes C can be an interpreted language with a C interpreter.
There exists hardware that can run it natively. Try again.
for the most part is irrelevant.
Java optimized processors exist. The jvm virtualizes said processors. That is the code that is being compiled down to.
Which is why I brought up 8086, according to your logic. Every language is interpreted.
Yes, in theory every Language can be interpreted.
Just a reminder that java and JVM were both made be years before Jazelle or anything like it came about.
This is why most people take Java to be interpreted, and it was designed to be interpreted.
Java, as a language, is not interpreted. Byte code is not the written language.
Typescript is mixed because Javascript is valid and not compiled in Typescript. It is more analogous to the C preprocessor, which is referred to as a macro language.
Scripting languages are not well defined, I utilize D as my scripting language, but it is fully compiled to machine code. Then you through in JIT and things get more confusing.
To better understand, it is best to look at the term for the time it was emerging. You had C and Bash, Lisp and Fortran. Languages like perl and php follow closer to the style for bash, these languages start execution at the file entry and don't define a special entry (main).
As for inferiority of scripting over a real language, we need to look at the level of understanding necessary to use the language.
Bash required writing your shell commands to a file then calling bash on it. Similarly languages like visual basic would add container iteration. C required learning pointers and memory layout. While scripts could easily build the description of a task, but would be limited in performance. Today machines are resource abundant and optimization techniques are identified.
C++ was long considered a compiled language, but it wasn't until Walter that the first compiler to build machine code instead of C existed.
Doesn't matter. Like even a little. There exists a hardware spec.
Anyway, here bud, user perspective.
Interpreted: code executes from human readable project.
Compiled: user compiles project, then runs output file.
From a user perspective it's that extra step that matters.
FYI "most people" is quite a stretch. I'll grant you that it's a debated topic. But the actual issue of this topic and why we're discussing it. Is that "interpreted" is actually not well defined, as people seem to think.
Some people consider vm languages like Java and C# interpreted because they typically run in vms, but there's really no reason they can't run on baremetal; we in fact proved Java can.
For me, this makes the most clear definition of the two, the user perspective I posited before. Because I can create an environment that all languages are interpreted based on the vm/emulator situation. You could certainly compile anything down if you try hard enough, as you stated before.
So from a user perspective. How do your execute your code. Does your human readable code get compiled down to lower level code, and then you get to run it? It's compiled.
Do you send your human readable code directly to an interpreter? Interpreted.
Basically, 2 step vs 1 step process.
I find your tone off-putting. There's no reason to be abrasive.
To the point people are making, they are correct. The fact an application is distributed in a way that's human readable is a minor distinction. That means more to the humans than the computer. They are all loading an application which does not contain native machine code and jitting it by the time it is executing. Node and Python are no more interpreted than Java is.
The major distinction is whether a language runtime needs to be preinstalled or distributed with an application. In that regard, c/c++/golang are in one category, and python/node/java/c# are in another
Well again. There exists a hardware spec for Java, you can run it natively with the correct hardware. So that goes back to my point of emulators. Just because you are virtualizing that hardware in most cases, does not mean you don't need to compile it down for that hardware.
In that regard c and Java are effectively the same. You just happen to have the hardware to run what gcc will shit out.
I believe you misinterpreted my human readable distinction. I was trying to explain what you pass through for the actual execution.
With traditionally accepted interpreted languages, you don't preform any extra steps to execute your code. Just throw it through the interpreter.
With non interpreted, you have to compile it down before the code will execute. That's how Java works. I also accept that some people claim Java to be interpreted, but in that regard you have a very gray area on what "interpreted" actually means.
Dude lol. They're not calling python/ruby/whatever legacy. It's the versions of those languages they ship with that are legacy, and quite frankly shouldn't be used anyway. Sure they could update them, but obviously they're lazy, and anyways we have very easy means to get most recent versions of these now days
A lot of software exists that relies on these languages that is not legacy, but their phrasing dismisses that reality altogether. That's what I'm referring to.
Which is part of my point. Apple is breaking the entire ecosystem instead of updating like literally every other UNIX-like system.
Define "easy". In my experience, it has never been obvious how to install anything of the sort on Linux. I've always had to use Homebrew to install Python, and OOPS, wasn't that written in Python? Hmm.
If someone isn't technically inclined, and many users aren't, would they really want to take the time to follow some convoluted process to install something they don't understand? It isn't even (IME) as simple to install as on Windows, where you only need to run a three-click installer.
The non technically inclined will certainly not be effected by this. You'd have to be technically inclined to have a need for python to begin with
Ya as a developer it's going to make my life slightly harder. There will be a bootstrapping problem. Apple is abandoning developers, I'm not arguing against that.
I was just being purposely pedantic on your statement about them calling the languages themselves legacy
Entirely untrue. Python is used to create quite a lot of end-user software, which now either must be packaged specifically for Apple, or will require Python to be manually installed on their machine. So, this will absolutely affect non-technically inclined people.
This is where you and I will not come to an agreement. I'm a firm believer that we should already be bundling python with our apps. No worries about compatibility, and easier for the end user. (IMO)
Big examples of this are eve online, and sublime text
If all the ui people got together and stopped the "fightin" and built one decent window manager with a decent ui with similar ux to macos... A huge number of people would switch.... Linux desktop needs to be easier. Example.. Compare time machine to what? Rsync? Or what? Exacly... Or what.
Apple has a lot of nice shit.. And you don't have to search high and dry to get something done. I like my nice desktop..
UI people are fighting? First I've heard of it.
The reason we have multiple window managers and multiple UIs is because everyone has different desires and preferences. Experimentation and free play of ideas is how we improve things. Projects tend to actually share ideas, but we don't force everyone to do things ONE WAY.
Linux is the LEGO-bricks of the computer world. You can build what you want, or select any of a dozen pre-built sets. If you don't like one, there are options to tweak it or change it.
Regarding backups, personally I've had good experiences with Duplicity, but there are several options depending on what you need. Also, Linux Mint has a system snapshots system that is on par with anything Windows or Apple has ever offered.
But, if you don't want to like Linux, you don't have to like Linux. Stick with Apple if you like it. Just understand that your problem is rooted in your perspective, not the realities of the OS. Your view isn't shared by thousands of happy Linux users. You're entitled to your opinion, just don't conflate it with objective fact.
It was handquotes fightin. Without the g. Meaning not really fighting but tension exists. And sure free reign and not forcing people to do thing a certain way fine. I agree with that. But Linux will never have a general consumer desktop that is popular because of this. I didn't say throw out the system. I said the system needs to adapt to general consumer needs of they want to blow out Apple. I think you missed the point my dude.
For the record I've been using Linux since Slackware 3. Not once did I ever say that I don't like Linux and you need to stick with Apple.
My computer repair clients, all of them non-technical, would disagree.
I suspect the only reason it doesn't have more market share is the fact that you can't walk into most stores and buy a computer with Linux already on it. The majority of general consumer users aren't going to install any operating system themselves. They'll only use the default.
OS popularity is a function of OEM installs, not OS merit.
I just hear a lot of empty griping about "Linux is broken because it isn't always default-identical to this thing over here that I already like." That's what your post sounded like.
Once again, not really. We live and let live. I hate KDE myself as a user, but I appreciate the fact it meets the needs of people who like it! That sort of attitude is common. We all have our preferences, which is why the existence of multiple DEs and WMs is so awesome. I seldom encounter anyone in the Linux world who feels their DE is unilaterally superior to all others.
ChromeOS. If there's one Linux desktop with any popularity at all with the general consumer, it's ChromeOS.
Nothing wrong with the term scripting language. It's a language which is compiled on the fly when executed. Scripting language have a purpose. Not just he domain specific languages like R, but also the more script generic languages like Perl and Python.
This is just more of Apple tightening their grip and narrowing their eco system. Apple lost their ways years ago.
About the definition of "scripting language" (that I do not consider a pejorative term). Missing a formal and precise definition, I personally would call a language "scripting" if
With this definition Ruby and Python are scripting language, while matlab/octave is not (they are used via a shell), neither Ada nor C (they are compiled). Note that Ruby has its "shell" irb that allows you an interaction with the language, but irb is used (at least, I use it...) just for "fast and dirty" tests, while the main way of use it is to write programs with it.
The definition above seems at odd with "shell scripting" since a shell is interactive by its own nature. Indeed, I personally do not consider bash (or csh, zsh, ...) a language, but an interpreter. The main way of interacting is via command line, but you can put the commands in a file too.
As said above, "scripting" is not (in my feeling) a pejorative term. Every language is a tool, and different problems require different tools. I personally use Ruby for simple programs (I noticed that maintaining gets difficult when the program is too complex), especially if they involve parsing text files (very easy with Ruby). For something more complex or long-lived I go with Ada that IMHO is more suited for writing complex software.
Well, see, you're still only describing interpreted languages, really, with some additional arbitrary criteria. You're welcome to categorize how you like, but it still lacks a real definition, and the meaning varies from one person to the next. Therefore, in terms of policy setting, the term is altogether useless.
Also, I might be missing something you're saying, but Python is very much used via a shell, although you can also execute Python programs directly.
There is a lot of large, complex software for which Python is well-suited. I, like thousands of developers, have created full-blown applications in the language, that are just as maintainable as, say, something written in C++.
Naturally, though, you can (and should) use what you work best in. Just remember that your experience is that: your experience. Plenty of developers are just as successful at making large, complex (and maintainable) software in so-called "scripting languages."
I agree with this much, at least.
I just see Apple's dismissing an entire set of languages, which have been used to deploy production software that people use today, as crummy garden-walling.
I used to have a MacBook that I loved (unibody was my last experience) and I was happy with it. I got some Bootcamp up and running and some VMs to learn Linux. After that I went to Lenovo, but I got a Yoga and didn't think about how it would be unfriendly with a Linux install compared to other ideapads and thinkpads. VMs still work though. If I had gone for the yoga thinkpad I would be running Linux natively for sure.
Add me as another former Mac developer who has made the switch to Linux.
If you read carefully, "legacy" refers to the software using those languages, not the languages itself.
Unfortunately the lack of lots of professional softwares it's a massive drawback for Linux, and no, the many alternatives are simply not a viable solution for the majority of professionals out there, having tried it myself many times.
What I was referring to is that a considerable amount of non-legacy software still being updated, distributed, and used relies on these languages, but their statement is rather flippantly dismissive of all that.
Hm. I've known quite a lot of professionals, and many are very happy with Linux software. I'd go as far as to say "a majority" I know do find that Linux is a viable solution. The past five years especially has seen major expansions of the software available on this platform, either directly or via compatibility layers.
But as for you, you know your own requirements.
Would never pay 2x for 1x worth of hardware. Terrible elitist strategy, I always held a grudge against them. Never had anything Apple.
Glad I made the jump after no nivida drivers for latest os
Python 2 (which comes preinstalled on OSX) is indeed a legacy version, EOL is set to next Jan.
But they didn't say "Python 2". They said "Python," which includes the non-legacy Python 3.
The smarter move on Apple's part would have been to switch the default to
python3.The rationale I heard was that no one uses the built-in versions of these runtimes anyway, opting instead to download their own version.
Four whole years ago? Oh boy, real trendsetter this one.
This is a really good point. As a Python developer, the very outdated system Python is a pain and is troublesome for everyone. I gave up years ago on Homebrew's Python3 even and switched to pyenv and never looked back. I suspect this isn't a unique annoyance for Python.
Homebrew could work around the lack of pre-installed Ruby by updating the installer to include the proper version of Ruby where Homebrew expects to find it - thanks to using an install script, Homebrew isn't actually the worst off. What gets hit especially hard are command-line programs that DON'T use installers, written in one of the affected languages.
As long as homebrew works your scripts are fine, because you can do "brew install ruby" (or rbenv if you need more control).
yeah exactly my point, but homebrew itself is written in ruby
Homebrew's creator commented on this on Hacker News. Unfortunately I can't find it but the solution is basically that they will add ruby to their installation process. A homebrew forum leader addressed it here.
Actively maintained projects will be fine. The ones who aren't will break unless you install the runtime you want yourself.
Lame move from Apple, pretty Apple-ish though.
This actually brings MacOS much more aligned with Linux philosophy. Most distros don't have tons of scripting languages installed by default, really just Python if I remember correctly. Bring your own toolset is much preferred in my opinion.
Yep, but Python is pretty important cuz I'm pretty sure there will tools needing that (even inside the OS).
Update: seems like Automator uses it
There's nothing to say a new release of Automatic won't bundle a python interpreter or give you a prompt that installs it (much like how Xcode installs CLI tools). That sounds like what Apple is urging devs to do, so I'd assume they will do the same with their apps.
What's their major purpose then? Or what are they aiming to achieve with that? Ridiculous to me.
Why is this a lame move? By removing factory outdated packages, you can use the version that you want without afraid of conflicting issues.
Good points. I have a soft spot for pre-installed Ruby because it helped me get started with Ruby development using campus machines back in the day.
Typing
irbon any Mac and hacking on some Ruby is a pretty nice feeling.Homebrew can't be easily rewritten in some other languages without denaturalizing it.
Homebrew is composed by the core tools and the formulas and while you can remake the first ones in some other languages, the problem lays with the last ones.
Formulas are written in Ruby, using a DSL combined with shell commands: you can check yourself with a simple
brew edit wget.This is different from usual Linux package managers who often rely on (almost) plain shell scripts. Because building instructions are Ruby code, Homebrew can often understand what the code is doing and not just merely executing it.
This characteristic is probably one of the advantages of Homebrew over other package managers and you can't easily replicate it if you rewrite it in other "more native" languages.
In the end, I think this move from Apple is a good thing: many Unix tools shipped with macOS are very old. For example, the bash version in Mojave is from 2007 (for license reason). Python and Ruby are also not at their latest version forcing many software like Homebrew to not use many optimizations and features. Moreover, many developers who use these languages need multiple versions of them, and they install them with tools like rbenv or pyenv.
I think is a good thing letting the community finds and provides the best way to install these interpreters instead of keeping old tools around and letting them rot for ages.
Doesn't seem like a huge deal to me.
I don't use all those languages, but the bundled version was usually an older one. More often than not you couldn't use it, and I just ended up installing the latest anyway.
Pretty sure most (if not all) have macOS installers.
They're not saying those languages are legacy, they're saying (other) legacy software is dependent on those pre-installed runtimes.
Seems to me like they're just not going to provide a decrepit version by default anymore. They're not pre-installed on all Linux distros or Windows. Seems like a sane thing to do to me.
Python 2.7.10 (2015)
Perl 5.18.4 (2014?)
Ruby 2.3.7 (2018)
So, not that old- especially Ruby.
I guess the point is the title makes it sound like Apple is "banning" scripting languages, which is not the case.
This will be slightly annoying for my job, where I have to use a Mac, I guess. But since almost everything I do runs inside docker containers which don't have this problem, I don't really care.
Apple can do whatever they want with their OS. It's not a development platform, it's a consumer desktop environment, and getting rid of obsolete versions of software makes sense, right? So they should ditch the version of bash they use that's from the 12th century. Except they can't because newer versions use licenses they don't like.
So rather than maintain semi-recent versions of software that's better served by containers, or old versions because of political reasons, just get rid of them. Most of the users won't notice.
This is exactly what I was thinking. Please get them out of my way so I don't have to remove them or try and get them out of my PATH. If you're going to install Homebrew, it's not much harder to also install Ruby or have the project do so for you. Linux distros don't come with tons of scripting languages, you have to install most of them if you want them.
Scripting languages may mean interpreted, and those include Javascript, HTML, Bash, Python, Ruby, Perl, make, awk, sed, Regexp engines embedded in grep, vi(m)'s config language, ... the list goes on and on and becomes esoteric at times. It's unclear to me why some might be chosen for elimination and not others. But I hope they go down this path while simultaneously producing ever worse keyboards; I need more people in my organization to push back and select a Linux based laptop for the good of those of us who have resisted the org's desire to optimize for IT rather than for those of us producing the code that provides the services we sell. Devs with Macs are almost cliche. I'd love for that to not be such a ubiquitous way of life.
Common internet generation skip reading problem, some of us cannot read as expected:
"bundle the runtime within the app."
Simple as that.
if (myApp.reliesOnScriptingLanguage && myApp.targetOS==macOS) {
buildScript.bundleRuntimeInstsller = true
}
else
{
buildScript.bundleRuntimeInstaller = false
}
buildScript.build()
Of course leave Runtime version hell to end users.
imho. Homebrew already installs some Ruby runtimes on Linux.
Actually:
"homebrew will pull in a temporary ruby binary to install itself (as it already does on linux and has done on older macOS versions"
Source: discourse.brew.sh/t/mac-os-depreca...
Interesting - for iOS this was always the case, ostensibly to prevent (or at least make harder) execution of things that aren't vetted through the app store or sandboxed in the browser. But this sort of supply chain control doesn't exist for macOS devices, so I guess they are simply reducing the support pain of all these moving parts and making them the developers problem? Perhaps instead they'll concentrate on supporting a decent package manager.. with an open ecosystem like Nuget or PsGallery, or one of the mainline Linux distros (Debian fan here)...
Full disclosure: never owned or operated a Mac since the Classic back in '92 that was on my desk when I got my first job drawing flow diagrams for speech systems.
Not bundling Python 2.x certainly makes sense, but that doesn't mean they should be dismissing bundling Python 3. Updating the runtimes is the only thing that makes sense...every other UNIX-like system does exactly that.
The issue, I believe, comes to when you have to ship to the end-user. In my experiencing, installing runtimes on Apple is not a piece of cake by default. A lot of non-tech-savvy users won't be willing to follow a long process to get some weird thing called (say) "Python" installed, just so they're able to run software. It's not like on Windows, where you only have to run a simple installer script...unless something has profoundly changed in the past year on the Apple ecosystem?
Now, sure, you can bundle the runtime, but this is an additional Apple-targeted packaging step that can be a pain in the butt for the developer.
It's practically impossible (although not technically) for Apple to block these languages from the platform altogether. The way I see it, this is the strongest action they can cook up a psuedo-justification of, wherein they discourage use of the language.
I don't know what all you are arguing about. They just remove preinstalled out-dated packages, which, as a dev, everyone prefer not to use and always installing a replacement like rbenv, python3. Homebrew already did check if ruby isn't available, then download it, as for old MacOS and Linux system.
I, for one, welcome this move
One of the difficulties with getting started as a Python or Ruby developer on macOS is coming to terms with globally installed interpreters and packages, and how these can clash with those in your projects
It also means there won't be future compatibility problems with interpreters being end-of-life'd, as in the case of Python 2.x
I would know - my "mass_scale2x" Python CLI program, which isn't published, is one of them. Fortunately, the issue is fairly easy to solve, since a published version would ALREADY have this problem by reliance on Python 3, which macOS does not include.
Just download ruby if not found. They already did that.
Including shell scripts ?
In any case this move doesn't seem to make any sense, does it ?
Thanks for the heads up. This move shows how little consideration they have for non iOS (or macOS) developers. Pretty lame and sad 😔
Does all the macs there lack for 30m disk space? 😂
I don't understand what you mean yet?
Yes they get in my way too. I need newer version of Python then the one that is installed by default.
I think what they'll have to do is bundle the interpreter along with homebrew. Either that, or they'll have to rewrite the homebrew installer (not the entire cli) in a different language.
The Linux version of Homebrew already downloads Ruby when it needs to, so they'll probably enable that functionality in the macOS version
Rust could be a good fit.
Comes down to the old adage - 'control the ENTIRE stack'
This way nothing can harm what you release(permit) ....
Mwa-ha-ha.
Did they rewrite xattr (and maybe other system tools) to avoid python already?
I think javascript is kinda important... also there are a bunch of good programs coded in python ie. Blender
Pretty amusing that AppleScript isn’t included in the list of legacy scripting language runtimes as it is probably the only one which actually is a legacy scripting language.