Apple project lead Ted Kremenek discusses Swift 5 & how it is used internally

AppleInsider

Apple's head of Swift development Ted Kremenek has provided insight into the development of Swift 5.0, the upcoming major milestone release for the programming language, with a podcast interview revealing not only what coders should expect, but also how Apple works out what new features to add to future versions.

Named the project lead of Swift development within Apple two years ago, Kremenek is the current manager of the Languages and Runtimes team, which handles Swift's refinement among other tasks. While Swift is being developed relatively openly, complete with its own dedicated website, Kremenek took time to discuss its development further in a podcast published on Tuesday.

Speaking on John Sundell's Swift by Sundell podcast, Kremenek discusses on ABI stability, referring to the application binary interface that works between program modules, with a stable ABI allowing for apps that are build with one compiler will be able to communicate effectively with those produced on another, for example. Kremenek explains the changes that had to be made to Swift to make it be ABI stable, and how the programming language stands to benefit from its implementation.

The podcast also covers how String has been improved in Swift 5.0, as well as how Apple uses Swift internally.

Swift is a core component of Apple's app ecosystem, and the company has been keen to teach others how to use the programming language as part of its Everyone Can Code sessions and larger software development curriculum in schools. Apple also teaches younger users how to code in Swift via the Swift Playgrounds app for iPad.

darkpaw

In this next version of Swift, will I suddenly get 4,000 errors due to fundamental syntax being changed? And if so, will that change be documented or will I have to hunt on Stack Overflow for the correct replacement code?

indieshack

darkpaw said:

In this next version of Swift, will I suddenly get 4,000 errors due to fundamental syntax being changed? And if so, will that change be documented or will I have to hunt on Stack Overflow for the correct replacement code?

The changes have become less onerous with new versions, but of course they're still there. I guess one of the reasons Facebook and other entities are still Objective C shops. Your point about documentation is well taken, and yes, StackOverflow will still be your friend.

hexclock

Just curious.. why isn't Swift Playgrounds on the Mac? Seems an obvious thing to do. 

ivanh

SWIFT is 30 years behind dBase IV in application development. We need application generator, not coding.

smiffy31

hexclock said:

Just curious.. why isn't Swift Playgrounds on the Mac? Seems an obvious thing to do. 

It is on the Mac. It’s part of Xcode.

welshdog

BTW: Everyone can't code.

IreneW

ivanh said:

SWIFT is 30 years behind dBase IV in application development. We need application generator, not coding.

Never did much real development, did you?

beowulfschmidt

IreneW said:

ivanh said:

SWIFT is 30 years behind dBase IV in application development. We need application generator, not coding.

Never did much real development, did you?

Perhaps he hasn't, but I have, and while his comment is more rhetoric than fact, the point remains valid.

That bit the article mentions about the ABI stands out.  Having not used Swift, I won't comment on the specifics, but I will comment on the general case.  Maintaining compatibility of interface between applications and modules built with different versions of a compiler is almost an absolute must.  Effectively cutting a new application off from old modules is a really dumb idea.  Lack of compatibility means that any modules I want to reference must also be recompiled, even if they're working fine.  This rebuild brings with it risk, since the new compiler might have changes that change the way the code works, or removes a feature used by the old code (these aren't issues most of the time, but I've seen them both, especially with some C compilers), which means the old module has to be reworked to work around the compiler issue.

Not to mention the fact that the older build might still be required by still other modules, which means maintaining multiple versions, with potentially multiple versions of the source as well.  Been there, done that, got the t-shirt.  No thanks.

Now, that doesn't mean the interface shouldn't evolve and improve, by any means.  Maintaining compatibility isn't that tough for a well designed compiler, and can be implemented in a number of ways.  As interfaces evolve, perhaps include the backwards compatibility for old builds in every newly built application.  Obviously this means including code might not ever be used.  Or perhaps a compiler switch that says "include compatibility for version X.X modules."  Better still if that detection were built into the compiler, so that when an older module is referenced, the needed compatibility is automatically included.

Lack of compatibility for modules built with older versions of the compiler (unless it's something like a security issue) just creates more, in most cases unnecessary, work for developers, including Apple's own developers.

MacPro

welshdog said:

BTW: Everyone can't code.

Oh thank you, I feel much better now.  

beowulfschmidt

welshdog said:

BTW: Everyone can't code.

Not quite correct.  Everyone can code.  Not everyone can do it well.

netmage

beowulfschmidt said:

welshdog said:

BTW: Everyone can't code.

Not quite correct.  Everyone can code.  Not everyone can do it well.

Your definition of code may be so generalized as to be meaningless. It certainly isn't mine. 

StrangeDays

netmage said:

beowulfschmidt said:

welshdog said:

BTW: Everyone can't code.

Not quite correct.  Everyone can code.  Not everyone can do it well.

Your definition of code may be so generalized as to be meaningless. It certainly isn't mine. 

Not really the point, as the phrase originated by Apple is in the context of teaching absolute beginners. Showing them that it is not, in fact, a mystic art practiced only by the techno-priest, but is in fact just a skill, like many others. It is absolutely a broad generalization. Like... Anyone Can Read, Anyone Can Cook, etc...

exceptionhandler

I’m reminded of the movie ratatouille: he didn’t mean “anyone can cook”, but “a good cook can come from anywhere”

mcdave

darkpaw said:

In this next version of Swift, will I suddenly get 4,000 errors due to fundamental syntax being changed? And if so, will that change be documented or will I have to hunt on Stack Overflow for the correct replacement code?

Xcode usually suggests the fixes directly.

mcdave

exceptionhandler said:

I’m reminded of the movie ratatouille: he didn’t mean “anyone can cook”, but “a good cook can come from anywhere”

Which you’ll never know unless we give the a go.  There are two things I like about commoditising technical implementation;
1)  it disempowered the technical experts who dominate product development decision-making and swings the focus back to the hard part.
2)  it makes implementation cheaper. Kinda like Uber turned the ‘profession’ of doing something anyone can do back into a cheap commodity.

mcdave

So a more robust ABI will increase the amount of third-party components moving apps away from first-party frameworks thus ensuring no hardware acceleration and everything looks like Android.  This isn’t a win in my book.

mcdave

welshdog said:

BTW: Everyone can't code.

Yeah but only like everyone can’t write.  With a little education its just not that hard. The problem is ‘coders’ have taken it upon themselves to design too and that’s the hard part but only due to their lack of subject matter expertise.  Implementing a well considered design is less demanding than most think, good designs are simple and require minimal technical implementation.
Of course, the  same rule applies; not all subject matter expert’s can design. 

tzm41

mcdave said:

So a more robust ABI will increase the amount of third-party components moving apps away from first-party frameworks thus ensuring no hardware acceleration and everything looks like Android.  This isn’t a win in my book.

I don't think that's what ABI stability means.

exceptionhandler

mcdave said:

welshdog said:

BTW: Everyone can't code.

Yeah but only like everyone can’t write.  With a little education its just not that hard. The problem is ‘coders’ have taken it upon themselves to design too and that’s the hard part but only due to their lack of subject matter expertise.  Implementing a well considered design is less demanding than most think, good designs are simple and require minimal technical implementation.
Of course, the  same rule applies; not all subject matter expert’s can design. 

“Simple” is easier said than done.

https://m.youtube.com/watch?v=R4C_JciDsuo

beowulfschmidt

netmage said:

beowulfschmidt said:

welshdog said:

BTW: Everyone can't code.

Not quite correct.  Everyone can code.  Not everyone can do it well.

Your definition of code may be so generalized as to be meaningless. It certainly isn't mine. 

As someone who's coded professionally since 1986, and as a hobbyist since 1976, I think my definition of "code" is probably pretty mainstream, and not over generalized.  For instance, I don't consider setting up a HomeKit scene to be "coding", though it can use some of the same skills.  Setting up tasks using one of the various "if this, then that" style apps is on the cusp of coding.  Writing a batch/command/script file on one's PC to automate a common task is definitely coding.

Coding doesn't take some arcane talent, it just takes time and effort, just like, as others have said, reading and writing.  It's something anyone can do should they be willing to put in that time and effort.  Learning to do it well however, can consume one's entire life.