
On Apple's Love Affair with Swift - doener
https://stefan-lesser.com/2018/06/20/on-apples-love-affair-with-swift/
======
pavlov
Chris Lattner writes:

 _”One of the best and most annoying things about Objective-C is that it has C
in it. This has been hugely important for Objective-C in practice, because if
you run into a performance problem with objc_msgSend, you can always rewrite
that algorithm in C. That’s really, really, really important for Objective-C
being successful in both in the days of NeXT on 16 MHz processors and also
today for the low-level code that people are writing.”_

This is indeed a great thing about Objective-C: it’s an improved C with a
tight set of runtime features that help build interactive applications.

There’s a need for such a language, and I’m sad that so much of the rhetoric
from Apple and the Swift community is working on the assumption that Obj-C
should be completely replaced by Swift.

Swift is not a compact language like Objective-C. It’s more like C++ in how it
tries to incorporate every programming paradigm that can possibly fit. The
heavy focus on complex upfront typing is not necessarily the best choice for
iterative app development.

Swift is useful in many places, but personally I found Objective-C’s
“Smalltalk-flavored C” to hit a sweet spot for my GUI needs where integrating
with C and C++ libraries is usually required all over the place.

~~~
pjmlp
Yeah, but you forgot to copy the other relevant part.

> The fundamental problem was Objective-C was built on top of C. C inherently
> has pointers. It has uninitialized variables. It has array overflows. It has
> all these problems that even if you have full control of your compiler and
> tool stack, you just can’t fix. To fix dangling pointers, you would have to
> fix lifetime issues, and C doesn’t have a framework to reason about that,
> and retrofitting that into a compatible way into the system just wouldn’t
> really work.

If you took away C from Objective-C, you couldn’t use C arrays on the stack,
for example. And if you couldn’t do that, there’s entire classes of
applications where the performance just wouldn’t be acceptable. We went
around, around, around. We said the only way that this can make sense in terms
of the cost of the disruption to the community is if we make it a safe
programming language: not “safe” as in “you can have no bugs,” but “safe” in
terms of memory safety while also providing high performance and moving the
programming model forward.

~~~
_ph_
I can understand the need to create a new programming langauge, but as the
previous poster wrote, they rather recreated all the complexity of C++,
instead of a more lean language. Also, Swift seems to suffer from overly
static typing in its object oriented approach - which defeats the idea of
object oriented programming.

~~~
masklinn
> they rather recreated all the complexity of C++

I find that this assertion holds about as much water for Swift as it does for
Rust, Swift is not even remotely close to C++'s in terms of complexity, and
that's with building in mechanisms for performant memory safety, a concept
which C++ literally just shits on to this day and for the foreseeable future.

------
sandbags
"It’s really about taking the best ideas from where we can get them and
assembling them together." ~ Chris Lattner

I think this is the root of my dislike of Swift. "Assembling" together the
best ideas, which may only be 'best' within a specific context does not
suggest the kind of design principles I am looking for in a language.

I was looking for a quote and it seems it was Antoine de Saint Exupéry who
said something like "It seems that perfection is attained not when there is
nothing more to add, but when there is nothing more to remove."

So I contrast Lattner/Swift with Hickey/Clojure: a small set of coherent
design choices that lead to a language that is simple but deep. It's by no
means all things to all women and that's a good thing.

~~~
wild_preference
Clojure clearly assembles various ideas as well, so your criticism is only
effectively leveled at a quote from Lattner which feels very superficial.

Surely every language designer including Hickey thinks they are assembling the
best set of features for their goals.

~~~
sandbags
I guess I am struggling to get across what I mean.

I see Hickey as having a specific, focused, goal about enabling simplicity
(given his specific meaning for that word) and yes I totally agree that every
designer, including Hickey, does as you say.

What I was trying to get across was that I don’t see the guiding principle
that guide the selection of those “best” features to include so much as
“there’s this great stuff” that we must include.

Does that make more sense? Or should I put down my shovel?

~~~
bgongfu
I get what you're saying, and I get the same feeling from most modern
languages. They lack conceptual integrity. It's sort of spreading like a
virus, even C++ fell into the same trap lately. Whole system design is
difficult, really difficult, tear your hair out difficult. Accumulating
features is a Sunday walk in the park in comparison; until the pile tips over,
that is.

------
spenrose
This is awesome: watch Lattner reverse the meaning of "working fast" to say
that the way to get something working fast is to prevent it from working at
all until you chase down all the corner cases. Slow is fast! Refusing to
compile is working! Up is down!:

\--------------

Swift ... really is designed and optimized for, as a programmer, you can spend
the least amount of time to get to a working program as fast as possible.

Getting to a working program includes the time it takes to debug something, to
iterate and develop and fight the type system, and all the other things you
have to do. But that time you spend having to fight the type system or figure
out optionals or things like that pays itself back because your program works
more often. You’re actually not spending time chasing own dangling-pointer
bugs

~~~
flipgimble
Lattner takes "working" software to mean something that can be shipped to
production and used in the real world, as opposed to the classic "works on my
machine" definition that second rate developers hide behind. It takes a
certain maturity and experience shipping to recognize the long term benefit
that approach. As the head of Apple developer tools (at the time), his job is
not to cater to the hobbyist working on his fun software project, but improve
quality of software on his company's platform.

~~~
wool_gather
There's a tremendous amount of value, in any creative task, in being able to
sketch out ideas quickly. The less time you spend seeing if the shape of the
thing you're making is broadly okay, the more shapes you will be able to try,
and the higher the chance that you'll converge on a good one.

Swift really does not support quickly iterating on a design. It demands that
you sit down with your plan fully-formed, ruler and protractor in hand. Due to
its strictness, changes ripple very quickly across even a small codebase.

Realized you need another enum case? You can't compile again until you touch
all your switches. Protocol would be more expressive with an associated type?
Stop what you're doing and write some type eraser boilerplate. Function needs
to signal an error condition? Try/do/catch anywhere you call it, right now,
before you run again. Need to put another type into that array? Write a new
protocol and add some conformances.

Changing a interface as you work in Swift immediately creates a sea of red
marks, which hinders the ability to experiment.

You're right that this strictness helps write ~correct~ safe code, and I
appreciate that. But it's a tradeoff; there's a real cost in developer
productivity/creativity. And I believe that it does not help produce the best
_design_. It takes too long to get to running, which makes it too costly to
heavily revise based on what you learn as you build.

EDIT: Actually, I want to go even further, and strike out "correct" in the
paragraph above. Swift helps at a certain _level_ of correctness, which is
really not much higher than the type system -- it would be better to call this
"sound" code, rather than "correct".

The overall point that I'm trying to make is that at the level of
application/business logic -- which is the whole point of the program, after
all -- Swift does _not_ help with correctness. In fact, it can be detrimental,
because, unless/until you understand your use cases well enough to actually
lift them into the type system, at that upper level it blocks exploration
without adding rigor.

~~~
flipgimble
> Swift really does not support quickly iterating on a design.

I find the opposite to be the case. You assume that compile errors are a net
negative for speed of development and expressivity. Instead I find that the
compiler reminds me upfront of all the places I would need to update anyway in
due time. In a dynamic language those inconsistencies would be found
hours/days later and usually after lengthy debugging. Instead I find myself
making large sweeping changes in the design very frequently, because I trust
the compiler to warn of any logical inconsistencies.

You have to admit at that this point it boils down to subjective preference.
You sound averse to the swift style of doing the right thing up front, and
using the compiler to help you stay consistent. I personally tired of the
hidden and unacknowledged costs of unsafe language, and compilers that allow
your design to degenerate into an unmaintainable ball of mud over time. I'm ok
with swift being an acquired taste and a technical advantage of folks who get
it.

~~~
kitsunesoba
This has been my experience as well. With Swift I’ve pulled off several large
shifts/refactors that I wouldn’t have even considered risking with Obj-C. My
Swift code is much further iterated than my Obj-C code.

------
vilhelm_s
> _There’s a number of things that rolled out over the years, and it was
> really funny at the time because the Objective-C developers externally and
> even internally to Apple always accused the compiler and language team of
> taking Objective-C on this random walk, and they didn’t know how it all fit
> together, and where’s the strategy, and why are you guys working on this and
> why aren’t you working on some other syntactic sugar that I want? Of course,
> we could never tell them, but there was a good reason._

Here it seems like Apple's culture of secrecy just hurt them for no reason. No
really, Apple, you can just tell people what your plan is.

------
AsyncAwait
To me, Swift is an ideal blend of FP/OOP for application programming. A lot
like Rust, but higher level. I understand that it's not for everyone,
(Objective-C isn't going away), but I really think this is the right design
approach modern languages should take.

------
mamcx
To me, the thing that will make swift the ideal language is solid support
outside the Apple ecosystem:

[https://www.reddit.com/r/swift/comments/8zb9y1/state_of_swif...](https://www.reddit.com/r/swift/comments/8zb9y1/state_of_swift_for_androidlinuxwindows_on_2018/)

I'm playing with rust to solve my use case, but is certainly hard. Is very
unlikely you can build a team of mixed developers and use it. Swift is more
forgiving, yet you can get great results anyway.

------
protomyth
They could have at least kept the clean messaging syntax of the Objective-C
(Smalltalk). The hybrid they chose was just painful. Plus, what is this
fascination with the comma. Adding commas has been a pain when trying Swift as
I am constantly skipping them.

They could have cleaned up all Objective-C and built a much nicer language,
instead we get a improved Java / C++.

~~~
saagarjha
What commas are you talking about?

~~~
protomyth

      somePoint.moveBy(x: 2.0, y: 3.0)
    

as opposed to

    
    
      [somePoint moveByX: 2.0 y: 3.0];
    

most Objective-C code would get rid of the space too

    
    
      [somePoint moveByX:2.0 y:3.0];
    

Its just painful to type extra characters that don't do anything and don't
help readability. Plus the weird splitting of the moveByX is still odd.

I still am mystified why they didn't just start with:

    
    
      somePoint.(moveByX: 2.0 y: 3.0)
    

to keep it inline with Objective-C and start working on giving the method
names an overhaul that would benefit everyone including the Objective-C
programmers.

------
lerno
I find myself wondering how many Swift converts actually wrote Objective-C
like it was supposed to.

I’ve run into a lot of programmers that worked with ObjC as they would Java or
C++, that is, using very small and fine grained objects to divide up the
problem.

It’s the standard way in Java. It’s also the opposite of how ObjC is supposed
to be, which is ”a few big classes” that uses message passing as glue.

How many former ObjC programmers actually heard of ”Software IC”?

Using ObjC like Java/C++, the language quickly becomes unwieldy and verbose.
If you do that, then obviously Swift feels like a huge improvement.

On the other hand, if you essentially write C and let ObjC be your reusability
layer, then Swift might feel like you’re back to working inefficiently in Java
/ C++ with objects all over the place.

~~~
batteryhorse
I definitely agree with you.

The way that I write Objective-C is to use 'id' for everything and have as few
classes as possible, mostly I just add methods to the existing classes mainly
NSString, NSArray, and NSDictionary.

Objects are interchangeable as long as they can respond to certain messages.
For example, any object can be an array as long as it responds to
objectAtIndex: and count. There was a whole discussion above about how
Objective-C doesn't have generics, but this completely misses the point
because Objective-C doesn't even need generics. "Modern" languages are not
necessarily an improvement, software generally does not get better over time,
it reaches a peak then it declines.

Objective-C is one of the best languages I have ever used, but the vast
majority do not understand it, even the ones who say that they used to write
Objective-C for X amount of years but now love Swift. The truth is, they never
understood the beauty of Objective-C.

I consider Swift to be a language for large teams of average programmers,
reading Lattner's response to Swift's criticisms tells me that he is a
compiler guy, but that expertise does not carry over at all to programming
languages.

I don't really like the direction they were taking Objective-C anyway, so in
the end it doesn't matter. I'm against things like dot notation for accessing
properties and ARC, I don't use either when I program in Objective-C. Those
recent changes end up making the compiler more strict and a pain to deal with.

~~~
lerno
Interestingly generics seem to drive the addition of type inference in order
to avoid having to write too complex types, losing the self documenting nature
of the static type, but still not avoiding the problem entirely.

Consider the types of some template generated pointers, or just something like
std::unique_ptr<std::vector<std::shared_ptr<Foo>>> (which isn’t a very far-
fetched example).

This is ”the generics problem”, where it actually starts having an obscuring
effect.

ObjC is immune to the problem since it lacks any need to do do the
specialization. Unlike Java where you needed a lot of manually inserted casts
without generics, ObjC doesn’t need them at all.

Like you say, dot notation, ARC, stricter resolution of dynamic messages etc
were weakening the strong points of the language and would push the programmer
towards a Java-like object model - which is very far away from how the
language ideally should be used.

------
m23khan
google’s push for kotlin and apple’s push for swift seems like ego-ism and
aiming for glory to me.

What new does kotlin or swift offer which python or ruby can not? Why reinvent
the damned wheel for syntax sake when they could have worked for their device
centric compiler for creating binaries out of python or ruby?

~~~
solidsnack9000
Kotlin and Swift are in a different family of languages from Ruby and Python.
The whole family that Kotlin and Swift are in — static languages — offers much
better performance and error detection than the family Ruby and Python are in.

Compared to Ruby and Python they doubtless seem a little verbose. Type system
features like genetics, which help to make Kotlin and Swift “expressive” in
their family of languages, seem pointless from the standpoint of Ruby and
Python.

So there are two aspects to this:

* What makes Swift or Kotlin compelling relative to other languages in that family? * Why use that family instead of languages outside it like Ruby and Python?

People have been promoting dynamic languages as an alternative to static
languages for many decades but it doesn’t seem like performance has ever truly
caught up enough.

~~~
samatman
This is true of the examples of dynamic languages you have chosen.

It is not true of LuaJIT, which is as dynamic as languages get. Error
detection and correctness, sure; raw performance is not the issue you've made
it out to be.

Ruby and Python were fair choices, together they must have 10-50x the
mindshare Lua does.

~~~
solidsnack9000
Lua and JavaScript are both examples of dynamic languages where the
performance is really impressive.

Lua (like plain JavaScript) is a more spartan development experience than Ruby
or Python. I'm not sure what it is; but languages with rich OO seem to be what
get picked up by people who need to build "applications" (windows where people
click around in them).

~~~
eatonphil
Common Lisp (SBCL anyway) and Chez Scheme are further examples of high
performance dynamic languages.

------
twic
> I think that Swift is more interesting than Rust in some of the higher-level
> application demands, but we’ll see

What does "higher-level application demands" mean?

~~~
bluejekyll
I’m assuming they mean that Swift generally is easier to use with dynamic
types than Rust.

Rust has dynamic polymorphism like Swift, but Swift you opt-out with final
(correct me please if I’m wrong here), whereas in Rust you need to promote to
a trait object.

This is a small difference, but means you’re starting with different
principles available to you out of the box. Personally I prefer Rust’s opt-in
to complexity model, but I can see why people see that as a hinderence, even
if it’s technically just as possible to do in Rust.

------
makecheck
There has definitely been this period of inconvenience where a language-in-
progress started taking over all the blogs, became the default language for
documentation and code snippets, etc. and even StackOverflow answers. And
using Objective-C becomes _surprisingly_ inconvenient with extra barriers to
finding help because lots is changing in Cocoa APIs too, etc. during the time
that Swift wasn’t fully baked.

~~~
saagarjha
But it’s pretty easy to translate between the two?

~~~
makecheck
To a point perhaps, and at least the official documentation can toggle between
them. After the Great Renaming though, things start to look different and
reading something like a code snippet is just a lot of mental translation.

------
amaccuish
The podcast itself: [http://atp.fm/episodes/205](http://atp.fm/episodes/205)

------
Froyoh
I thought you were Stefan Esser
([https://twitter.com/i0n1c](https://twitter.com/i0n1c)) for a sec

------
sheeshkebab
Swift is nice, although it’s too close to objc.

I think it’s time for Apple (and Google) to embrace JavaScript as the app
development language.

~~~
thosakwe
Why JavaScript, out of all languages in the world?

I don’t think that’s a particularly great choice.

~~~
jmpt
Large headcount of developers. Everybody and their dog does Javascript.

~~~
DannyBee
If that's your metric, java has many more developers (millions more, in fact).

