[–] tentaTherapist link

You say 'beloved Objective-C'. Sorry if this is really off topic, but is objc_msgsend (the whole late-binding thing) or anything else about Objective-C particularly appealing? Maybe the decent unoptimized speeds or the fact that you can use plain C whenever?

reply

[–] waynecochran link

I love C because I do a lot of low-level programming and I feel closer to the machine with C. For higher level UI stuff I like the Smalltalk extensions to C and Obj-C's dynamic nature and the fact that I can use C (and C++ directly).

Also I have been programming the Mac for a long time and I have a lot of mental investment in Objective-C.

OTOH, I do like the functional, strongly-type features of Swift, but like any higher level language I feel more removed from the machine. That's the price for abstraction.

reply

[–] cageface link

I prefer Swift for general purpose iOS development but I have one app that leans heavily on a lot of C++ DSP code and that one is likely to stay ObjC just because interfacing ObjC & C++ is so painless.

reply

[–] Razengan link

You could mix Objective-C and Swift.

reply

[–] waynecochran link

You can, but not as easily.

reply

[–] bluedino link

>> I switched back to my beloved Objective-C for the app I was developing.

Can you write the app in Swift (if there are advantages to doing so) and then write the image processing routines/library in C?

reply

[–] waynecochran link

Yes, but I hate figuring out the bridging stuff when I can just use C directly in Objective-C.

reply

[–] adamnemecek link

The bridging is pretty straight forward no? You add a bridging header and put in all the headers you want to expose to swift and you are good to go.

reply

[–] waynecochran link

Pretty straight forward, but there is zero friction when using Obj-C.

reply

[–] auggierose link

I found that when doing lots of array code that needs to be fast, you cannot rely on the high-level abstractions of normal Swift. But even while staying in Swift there are API's to drop down to, lower levels of array manipulation etc. where you get the speed of raw C (independent of your optimisation settings).

reply

[–] waynecochran link

Yeah, but the amount of code and API's for C make using Swift a bit of a pain when using the two.

reply

[–] pjmlp link

What about using unsafe Array access if you want C style code?

reply

[–] waynecochran link

Optimization makes a huge difference with arrays in Swift. The following took 2.37 seconds (!) on my machine un-optimized:

     var bytes = [UInt8](count: 16_737_732, reapeatedValue: 0)
This was slow enough to block my UI (spinning pizza) -- so I ran it on a background thead!. Turn on optimization and it took a more reasonable 0.0165 seconds. BTW, took C's memset only 0.00827 seconds on the same machine.

I switched back to my beloved Objective-C for the app I was developing. Won't be using Swift for low-level image processing.

reply

[–] ovao link

I imagine because Swift famously touted the ability to use emojis as identifiers.

reply

[–] jmull link

Reading these things makes me hungry.

I think it’s because that’s the style of Apple’s own (excellent) Swift Programming Language book.

I think it does look nicer than the traditional characters used in these kinds of things.

reply

[–] drak0n1c link

The language supports emojis, and the point of example code is to be as concise and easy to understand as possible. Better than foobar.

reply

[–] proyb link

Easy, our mobile devices screen width is limited. Emoji is the idea and it make learning not boring.

reply

[–] tzahola link

Why does every Swift article use emojis in their code samples?

reply

[–] Someone link

This article says ”Array can be toll-free bridged to an NSArray”, but is the reverse true, too?

https://developer.apple.com/library/content/documentation/Sw... says the two are bridged, but doesn’t mention whether that is toll-free.

If that is toll-free, users of Array, just as users of NSArray, should be aware that indexing in them can be O(log n). See http://ridiculousfish.com/blog/posts/array.html

reply

[–] undefined link
[deleted]

reply

[–] valuearb link

Almost always, worrying about arrays is premature optimization.

reply

[–] whowouldathunk link

On the contrary, developing a good intuition about stuff like this so you get it right the first time is a big time saver in the long run. Especially when it's no extra code to do the better thing to begin with.

Good developers have battery empathy.

reply

[–] pjmlp link

Good developers know when to use profilers.

reply

[–] jcelerier link

thanks for your contribution to my job safety :p

reply

[–] dep_b link

Very fascinating stuff, also follow the link at the bottom of the article towards another explanation with visuals how arrays are structured.

Honestly I never run into performance problems since the volume of data I work with is either really huge and done in a C or C++-based library or so small I would never think about array performance.

reply

[–] undefined link
[deleted]

reply