I agree with you. Speaking about Markdown is forum meta, not content.
Sorry if I violated some rules.
Thank you for cleaning up the organization and maintaining the quality of the discussions. I promise to do so as I get better at this.
If with "so" you are referring to "maintaining the quality of the discussions", I think you are already pretty good at it 
(no offense meant!)
Exactly what I meant.
I can’t even imagine an interpretation I’d take offense to and I’m not on the defense, fence, or offense about it. 
You are a good and kind man, Tom, thank you for being supportive!
Just reading https://www.cultofmac.com/629988/swiftui-wwdc-2019/ and in talking about the evolution of Apple’s software it said “Before [rejoining Apple in 1997] Steve Jobs was CEO of a company called [NeXT], which produced a cutting-edge operating system called [NeXTSTEP]. Applications for NeXTSTEP were developed in a programming language called [Objective-C].
Apple purchased NeXT because it needed a shiny, next-generation operating system to replace the aging System 7 that Macs ran on at the time. Cupertino adapted NeXTSTEP to become Mac OS X, which later morphed into the macOS, iOS, watchOS and tvOS we know today.
Even after all these years, if you take a look under the hood, the origin of Apple’s platforms remains clearly evident. The names of the object classes Apple uses in its code start with the letters “NS,” for “NeXTSTEP.””
I’d be seeing all those “NS”s in front of things and thinking they had some deep technical meaning I’d someday learn after much pain and suffering from shedding all the blood, sweat, and tears needed to know such lofty things. Nice to discover its much more earthy and relatable origins as that makes the seemingly cold and impersonal machinations of coding much warmer and approachable 
.
Some friendly tales and bantering around the camp fire to accompany and enhance the creative act of learning a new language seems inviting.
Hoped so. I added the “no offense meant” only to make clear that there is absolutely no irony involved. (Since by nature I’m more the ironic, sometimes sarcastic type of writer/commenter.)
Thanks for pointing to that good article, especially since I didn’t yet find the time/patience to dive into all the “details” of this year’s WWDC.
And yes, news from the campfire, like this, are incentive also to me to not let down my combined efforts to learn Swift / macOS UI / iOS UI programming, which will ultimately result in the creation of a nice app that will yield me a constant income of €1500/month. [emoji of your choice here]
Besides that I also perceive learning a new language as something really creative. Learning frameworks not so much. (Possibly has to do with the “frame” in “framework” 
)
Just coming across articles about scripting languages being depreciated over the next couple of years:
What does this mean in relationship to my nascent AppleScript ambitions? Would it be a better long-term plan to focus on Swift or elsewhere?
I gleaned that with additional work things will continue as before for a couple of years and reading the tea leaves is always tricky, still, this seems be suggesting a significant change in the making.
I don't yet understand the larger structure that scripting fits within and so can't fully appreciate what these articles are saying. If anyone would translate into a CliffsNotes-ish conversation for us neophytes I'd appreciate and maybe understand a little more.
Nothing, I think.
I don’t see AppleScript mentioned anywhere in these articles. And AppleScript is certainly not a “UNIX scripting language”.
Concerning the other scripting languages (Ruby, Perl, Python, …):
The current situation is this:
macOS comes with these languages pre-installed, but usually not in the latest versions. So, if anybody does some active scripting in one of these languages, the usual first step is to install an up-to-date version of the language (e.g. via Homebrew or MacPorts).
As a result you have two instances of the language on your computer: 1) the outdated version that came with the OS, and 2) the up-to-date version you installed yourself.
This can lead to confusion, because you always have to make sure that your PATH variable gives precedence to the up-to-date version. On the other hand, you don’t want to uninstall the pre-installed version, because it is not transparent whether the OS itself is actually using the language (for example for some internal maintenance scripts or similar).
So, for most users it is probably an improvement if Apple gets rid of the preinstalled languages, because you don’t have to worry anymore if your script runs with the correct version of the interpreter. (And obviously we save some disk space by only having one instance of each language on the computer.)
As mentioned in one of the linked posts, the removal of the languages will be a not so good thing, if you are working as macOS service technician, because you can’t any longer run for example your Perl check/repair/cleanup scripts on a client’s computer. You’ll have to install Perl first, or bring your own Perl on an external disk.
I hope this helps and didn’t add more confusion
1 Like
Another thing worth to think about:
Without the pre-installed languages in future macOS versions you might think it will become more complicated to post Perl/Ruby/Python/etc. scripts on forums (or KM macros that contain such scripts).
I don’t think so. Right now (with the pre-installed scripting languages on every Mac) there are potential portability issues. To eliminate portability issues you have to do one of two things:
-
Before posting, test your script/macro against the macOS pre-installed language version. Problem here: 1) More work, and 2) if someone is using an outdated OS version, he will still have a different default language version on his Mac than you.
-
You tell the user to install the up-to-date version of the scripting language, for example via Homebrew, before running the macro/script. Problem here: For some users it is difficult to install something with a command line tool like Homebrew. And you also have to explain how to set the correct PATH, or ENV_PATH in KM.
In the future – without any macOS pre-installed languages – you only have option 2: The user must install the language on his computer. After an initial “acclimatization” period everyone will have understood that a language that is required for a macro has to be installed on the computer. And doing this will become a more normal thing.
At least I hope so.
Hey Bern,
Apple is fixing AppleScript bugs in Catalina, so I don't think we have much to worry about for a while.
The day automation leaves the macOS I will too, and I'm not alone.
A Mac without adequate Automation is about as useful as a balsa wood boat anchor.
-Chris
1 Like
Yes this is a longer term look down the road consideration.
Looks like automation remains firmly in place. It’s the form it may take that’s Applely unclear. 
Thanks!
Thanks Tom! That’s clearer and useful to be aware of. I appreciate that. 