Petition Apple for AppleScript 3.0

AppleScript
#41

I believe they’re referring to the fact that the integer type has a maximum positive or negative value of 536,870,911 (which would make it a 30-bit value…); 64-bit values are needed in many places nowadays.

AppleScript actually has a double integer class that should hold a wider range of values, but it’s not implemented properly & is not very useful.

(example of the only place I've ever used it) 
to roundTo(n, decimal_places)
	(*    (number, integer) → number
	
	Return n rounded to the nearest decimal position specified by decimal_places. Accepts negative decimal_places. If decimal_places is 0 or less, the return type is integer, otherwise it is real.    *)
	
	set rounded_n to n * (10 ^ decimal_places)
	set rounded_n to rounded_n as double integer
	set rounded_n to rounded_n * (10 ^ -decimal_places)
	
	if decimal_places is greater than 0 then
		return rounded_n
	else
		return rounded_n div 1
	end if
	
end roundTo

roundTo(2.333444555666E+10, 0)
-- returns 2.3334445557E+10, rather than erroring out if "as integer" is used

A silly example here, perhaps, but I only came across double integer because the above handler choked with a regular integer.

For what it’s worth, I understand a lot of the sentiment here, but agree with Mark (and Hamish) that AppleScript doesn’t really have a viable future. It really is a pig of a language, and a lot of its “magic” comes from the first-class Apple Event support it receives from applications & its integration with macOS as a whole.

I think Swift would be the obvious way forward, if Apple was able to provide better support for scripting using Swift, with a proper Apple Event bridge, tooling, and some minor additions to the language that would take away the friction of using it for scripting (some sort of source “import” function, support for loading local swift packages similar to swift-sh, a more permissive syntax mode, etc).

Proper Swift scripting support would at least address a lot of the pain points of AppleScript while waiting for Apple to get their automation strategy sorted (if indeed that ever happens). It would provide a clear path forward for those of us who love AppleScript for what it can do (even if we don’t love the language itself).

#42

スクリーンショット 2022-09-26 13.54.56
スクリーンショット 2022-09-26 13.54.56997×433 97.2 KB

#43

We don’t have some suppoort in making Siri-like natural language interface program in AppleScript, 2002.

Now we are making more powerful solutions in AppleScript. But Apple make a lot of bugs in their OS and frameworks very frequently.

They may be able to make new functions and they can not fix their own bugs.

I don’t have any support from Apple. And Apple hinder us to make solutions.
Is it a neglect? No. It is a kind of no quality control.

#44

Until just over a year ago, I’d never written a script in my life. Now I have hundreds of them. I’d say that I am pretty much exactly the target market for AppleScript. Low skills, complex needs, willingness to learn.

AppleScript seems to me to be an amazing idea that was about 70% realised by the mid-2000s, and is about 69% realised now… Since then, Apple has gone from being a computer company that happens to make phones to a phone company that happens to make computers. Its future seems to be as services ecosystem that uses its hardware for user lock-in.

What that means for AppleScript/Apple Events, I have no idea. What I can say for sure is that I would never have learned to code if it wasn’t for AppleScript, but then I would never have learned AppleScript if it wasn’t for Script Debugger.

It was really a revelation when I realised what I could do with these tools. But also that I could do these things with these tools. It was all a big black box to me until one day I looked at the Script Debugger Explorer View, and realised ‘Ah! So that’s how it works!’ It got me over that hump in the learning curve that had always defeated my curiosity in the past.

Obviously AppleScript users are a fringe of a fringe of a fringe from a commercial point of view. However, there are quite a few mainstream apps out there that rely on AppleScript for their feature set. Also, while Apple is a vast, ruthless, profit-pursuing machine, one thing that they have given much greater attention to in the past than would be strictly necessary for business purposes is accessibility.

If, in some wild nightmare, I had to make a pitch for AppleScript’s continued existence to an Apple exec, I would probably emphasise how important this integration is for accessibility purposes. In fact, that’s basically how I got into Mac automation. I suffered really terrible RSI and had to figure out a way of working. AppleScript has become absolutely integral to my life for that reason. (And because it’s fun.)

So, while I have no doubt that Apple would shut down AppleScript at some point for brute commercial reasons, I very much doubt they’d do the same for accessibility functions. That would be a PR disaster. That’d be how I’d pitch it anyway…

Long story short, vanilla AppleScript sucks. We all know that. But, whatever the opposite of vanilla is (I’m gonna say Neapolitan AppleScript), including Script Debugger, FastScripts, all the third party libraries, and all the shared knowledge going back 20+ years… that is pretty amazing. I’d certainly miss it if it was gone. However, learning AppleScript has given me the start I needed to learn other things too. So, while it would be a pain, I don’t think it would be a disaster, for me anyway…

1 Like
#45

@meltcow @Piyomaru is one of the top. very few as knowledgable. excellent web blog AppleScriptの穴 – Useful & Practical AppleScript archive. Click '★Click Here to Open This Script' Link to download each AppleScript you have to use a built in translator for the site…answering:

You sound like you have much experience with AppleScript, Piyomaru, and I can only imagine your frustration with Apple for neglecting this amazing technology for so long

#46

I agree. It’s very useful.

#47

I agree. I’m a heavy user of Adobe Creative Suite products, all of which have detailed AppleScript dictionaries.

2 Likes
#48

The (signed) integer type can represent values in the range [-2³¹, 2³¹ – 1], which is 32-bits (the corresponding unsigned integer type obviously has the same number of bits to represent positive numbers, so shifts this range to [0, 2³² – 1].

What do you mean that it’s not implemented properly ?

The documented value for NSUTF16BigEndianStringEncoding is the hexadecimal value 0x90000100₁₆, which, when converted to denary, is 9×16⁷ + 16² = 2,415,919,360₁₀, represented in scientific notation as 2.415919360E+09.

Likewise, NSUTF16LittleEndianStringEncoding has the hexadecimal value 0x94000100₁₆, which is represented in denary as 2,483,028,224₁₀, or 2.483028224E+09.

Both of these values are the values returned by AppleScript, which can be visualised textually:

use framework "Foundation"
return my NSUTF16LittleEndianStringEncoding as miles as string
--> "2483028224"

So I’m not seeing an issue here. While it’s outside of the (signed) integer range, it’s within the range of unsigned integer.

Part of your concern may stem from the two orders of magnitude you’ve shaved off your estimate for AppleScript’s “numeric range”. It’s not clear what you’re evaluating here, although @tree_frog has a similar estimate for the integer type, so I presume your estimate also pertains to this.

This demonstrates the actual size of AppleScript’s integer type, which is exactly what one would expect it to be:

set i to 1

try
	repeat pi ^ pi times
		set j to i
		set i to i * 2
		result as integer
	end repeat
end try

set k to j - 1 as integer
return j + k as integer
--> 2.147483647E+9
#49

If more application get better to solve different tasks and do it more efficiency. Scripting language could only fill other tasks. The question is why would a application benefit to be scriptable if the working flow is everything and be productive. Creativity and user inputs is still the main thing for most application. And that’s why few developers do not see the benefit. That said there are plenty of examples of more complex ideas that scripting language have benefit users and productivity.
ex. python in 3d application

I couldn’t say I have seen any AppleScript of that kind include Apple so it comes to my conclusion simple ideas only serve the people who couldn’t see the greater things.

#50

Well, somebody here has quiite the ax to grind with Apple! :laughing:
I like Applescript so “I agree” and I hope Apple continues to support and update it.
But I’m not delusional, and Applescript may be on it’s way to bed. I also don’t think that you will ever have millions of Apple users clamoring for automation whether it is Applescript or something better — most people don’t want to put it in the time to learn how to script and only a small number more will take the time to learn something like Shortcuts. If Applescript is abandoned, I just hope that Apple provides something that is functional and useful. Most Mac users won’t care, but the small portion of people here certainly do.

#51

Sorry it took me so long to get around to responding! Examples required. :slight_smile:

Actually, it can’t! But AppleScript tricks you into thinking it can. The range really is [-536870912, 536870911], i.e. [-229, 229 – 1]. Anything above that is silently coerced into a real.

set biggest_int to "536870911" as integer
set too_big_int to "536870912" as integer
set way_too_big_int to "1234567890123" as integer

return {class of biggest_int, class of too_big_int, class of way_too_big_int}
--> {integer, real, real}

So, above 229, coercing to an integer silently returns a real.

Above 231, which is outside the bounds of a signed 32-bit integer, still silently returns a real, even though the value is too large for an integer!

However, when trying to coerce from a real above 231 to an integer, you get an error (which is good, but different than the above).

set way_too_big_int to 1.234567890123E+12 as integer -- same value!
--> error

It’s not even possible to write a literal integer higher than 536,870,911, or 229. It is changed to a literal real at compilation.

AppleScript also does the following naughty things (same values as literal numbers):

set biggest_int to 5.36870911E+8 as double integer
set too_big_int to 5.36870912E+8 as double integer
set way_too_big_int to 1.234567890123E+12 as double integer

return {class of biggest_int, class of too_big_int, class of way_too_big_int}
--> {integer, real, real}

The same applies to unsigned integer. Bad!

So, in essence, AppleScript makes it very difficult to work with large integers, since they often have to be dealt with as strings, and the silent coersions are dangerous.

I know this is really off-topic to this thread, but I thought it worth sharing! It’s not at all obvious.

2 Likes
#52

Short and to the point: adding my vote :slight_smile:

Rodney

#53

It seems this thread has generated a considerable amount of interest.

So… I’d like to ask – what’s next? After all, this thread was about petitioning Apple to improve it’s support for AppleScript and automation in general.

It’s clear that most of us are quite invested in AppleScript. I certainly am, despite its many shortcomings as a language. As I said above, I think better scripting support in Swift would be the most logical path forward for Apple, but that’s just wishful thinking on my part. I certainly would be content with an end to Apple’s neglect of AppleScript – there’s a lot that could be done to fix some of the pain points of the language.

It’s all well & good for us to discuss it here, but unless some action is taken it ultimately served no purpose… However, I don’t know how to get Apple’s attention. I don’t even know if someone like Mark or one of the other prominent AppleScript-focused developers could get Apple’s attention on the matter. Personally, I don’t know any macOS engineers.

Is there a path forward here?

1 Like
#54

Absolutely. This is an excellent reply and offers a level of detail about which I was not aware. Thank you.

1 Like
#55

I certainly agree that AppleScript should be kept up to date.

#56

I agree that Apple should keep AppleScript forever and should update it to AppleScript 3.0. That’s the most important thing that should do, more important than the iphone or watch stuff.

#57

I agree.

Use AS to extract certain pages from very long STANAGs creating new documents for testing. Used to summarise project progress stored in an Omni Outliner output to an email. Creates a Year Planner populated with events from calendar in Omni Graffle. Export Omni Outline to Excel with legal numbering of rows. To-do list in Omni Outliner and many other scripts over the years.

Automation is one of the reasons my family all use Apple products.

1 Like
#58

I agree. I think there is no valid alternative to AppleScript

#59

Perhaps hard to measure, other than by revenue ?

#60

I agree. MacOS without AppleScript is a no-go. Apple, please do your homework.

2 Likes