Important question, please?


Brian Christmas
 

G’day Scripters.

Apart from several weeks of thorough testing, it appears my 10-years-in-the-making App is ready for Public release. I might actually be able to stop annoying you all!!!

Thank you to a whole bunch of people in these lists, in particular Shane Stanley, and Yvan Keonig. Apologies to anyone else who feels they deserve a mention.

However, it’s operational scope has grown so much that I’m a bit disappointed in the amount of overhead processing time each email takes. Each image in an Email prints in about 10 seconds, but 35-50 seconds minimum is added for each Emails background processing and Data saving.

I’m wondering, now I’ve got nothing to do, would converting much of the code to Swift in the main Apps Part 1 speed it up much? (The main Apps in 3 parts, which work together; part 1 is 14,000+ lines, running 24/7). Swift simply wasn’t around when I started this whole thing.

Lots of file reading and writing. Disk intensive. Lots of RAM minimizes this. 32GB recommended. It uses over 12GB without extra caching.

I’ve read this link below, and the procedure seems straightforward. I just thought I’d ask the Guru bunch if I’d be wasting my time.


Regards

Santa


2551phil
 


On 20 Sep 2017, at 07:22, Brian Christmas <ozsanta@...> wrote:

I’ve read this link below, and the procedure seems straightforward.

I don’t believe there’s an AppleScript-Swift bridge, so you’ll have to translate your ASObjC and vanilla AppleScript code directly into Swift. That will not be straightforward.

I’ve spent the last two months (re-)writing one of my Objective-C apps in Swift, and it was far from easy. Quite besides the fact that similar sounding Swift classes like String and Array do not behave like NSString and NSArray (although you can bridge to the Objective-C versions if you want), Swift is by design far more intolerant than Objective-C. It was made for iOS devices, where crashing is preferable to having an app performing inefficiently on hardware where memory, disk space and particularly battery life are in short supply. So you’ll find that things that wouldn’t have crashed before will crash now. Of course, that’ll make you a better programmer; it may not do much for your head and the wall nearest to it, though.

But put all that aside. You’re tenacious. If you want to do it, I’m sure you’ll do it. A far more important consideration is why Swift? The name is a misnomer. It’s got nothing to do with speed, whatever Apple might say, and in many places it is interwined and reliant on Objective-C under the hood (one unpublicized reason why Apple confidently say ‘Objective-C isn’t going anywhere anytime soon’).

If you’re looking for speed increases, by all means get away from AppleScript, but a better choice would be to  put as much of your code into Objective-C as you can. You’ll also be far more comfortable with it, as the syntax will both look and behave in familiar ways. 

You’ll also find it easier to get help with Objective-C than Swift (Swift 1, Swift 2, Swift 3, Swift 4 - changes abound). About the only good thing I can think about Swift is that Xcode’s codesense / static analyser is far more helpful for Swift than it is for Objective-C. Oh, and it sounds cooler, of course. 


Best



Phil
@sqwarq


Bob Stern
 

On Sep 20, 2017, at 6:49 AM, 2551phil <2551phil@gmail.com> wrote:

I’ve spent the last two months (re-)writing one of my Objective-C apps in Swift, and it was far from easy.

@Phil: Considering all the shortcomings of Swift that you described, why did you expend the time to rewrite such a major program in Swift? Was there a benefit offsetting the shortcomings, or was it merely a learning experience?

Bob Stern


2551phil
 


Considering all the shortcomings of Swift that you described, why did you expend the time to rewrite such a major program in Swift? Was there a benefit offsetting the shortcomings, or was it merely a learning experience?

I have had an iOS project on the backburner for a couple of years. I thought it’d be (as you say) a good learning experience to update an app I’d already written in Objective-C into Swift as prep for starting on my iOS project. In hindsight, I should have learned the language from the ground up and saved myself a lot of pain.

I do like some parts of the language’s syntax (those parts where it’s sort of python-esque), and I do like the absence of header files and the ease with which you can “talk” to other classes. I think it’s primarily all the extra type casting that I don’t like and the constant irritation of unwrapping optionals left, right, and centre. Collection classes like Arrays and Dicts are no fun to work with, and String is no equivalent to NSString, IMO. Using all three requires more typing than doing the equivalent in Objective-C and a lot more than it would in Python. It’s frustrating to see the Python-influence in some places and not others where it would have made so much sense.

Python: len(hello_world)
Objective C: hello_world.length
AppleScript: hello_world’s length
Swift: hello_world.characters.count

I don’t doubt Swift aficionados will argue it’s just different and has many benefits I’m not aware of, and I’m inclined to agree that with more familiarity I might love it a little more and hate it a little less. However, the point would still remain, bringing this back to Brian’s scenario, that you don’t want to be learning Swift by trying to rewrite something as complex as his project, especially not when the motivation is only speed of execution. Swift won’t help with that. Reducing the AppleScript calls wherever possible will though, and I believe he can do that with much less brain hurt in Objective-C - a language he’s already partially familiar with - than in Swift.



Best


Phil
@sqwarq


Shane Stanley
 

On 22 Sep 2017, at 10:38 am, 2551phil <2551phil@gmail.com> wrote:

Objective C: hello_world.length
AppleScript: hello_world’s length
Swift: hello_world.characters.count
FWIW, I believe the latter is now hello_world.count. And perhaps more to the point, it matches what AppleScript returns (the number of grapheme clusters), as opposed to what Objective-C returns (the number of uniChars or 16-bit values).

--
Shane Stanley <sstanley@myriad-com.com.au>
<www.macosxautomation.com/applescript/apps/>, <latenightsw.com>


2551phil
 

On 22 Sep 2017, at 07:54, Shane Stanley <sstanley@myriad-com.com.au> wrote:
FWIW, I believe the latter is now hello_world.count.
That’s a Swift 4.0 change, I see; different from Swift 2 & 3, which were themselves different from how to get the length of a string in Swift 1.2 and later, which wasn’t the same way to do it in Swift 1.0.

Wonder what it’ll be next year in Swift 5…


Best


Phil
@sqwarq