
Chris Lattner on the Realm WWDC 2017 Swift Panel - king7532
https://oleb.net/blog/2017/06/chris-lattner-wwdc-swift-panel/
======
smaili
> What irritates me is when people say classes are bad. Or subclassing is bad.
> Thatʼs totally false. Classes are super important. Reference semantics are
> super important. If anything, the thing thatʼs wrong is to say, one thing is
> bad and the other thing is good. These are all different tools in our
> toolbox, and theyʼre used to solve different kinds of problems.

Couldn't agree more

~~~
legulere
The issues with inheritance based OOP are that it fits very few problems well,
that it usually causes lots of problems and that many programming languages
only have inheritance based OOP in their toolbox.

Java is the extreme case of this. Patterns like abstract visitor factories are
hacks to express situations that cannot be expressed in an obvious way.

~~~
soulbadguy
> The issues with inheritance based OOP

Inheritance is just one of multiple facets of safe code reuse in OOP.
Aggregation, composition, encapsulation are as are much as fundamental notions
in OOP as inheritance. So i think reducing OOP in general, and java in
particular to "inheritance based OOP" is a miss characterization

> are that it fits very few problems well, that it usually causes lots of
> problems and that many programming languages only have inheritance based OOP
> in their toolbox.

Do you have any objective way to measure that ?

> Patterns like abstract visitor factories are hacks to express situations
> that cannot be expressed in an obvious way.

But isnt that the reason to have a pattern ? An easy way to expression a non
obvious recurring situation ?

~~~
lomnakkus
> Aggregation, composition, encapsulation are as are much as fundamental
> notions in OOP as inheritance.

You say that as if these things are not just as easily expressed in FP -- if
not even easier.

Aggregation is just records-of-records.

Encapsulation is just "abstract data types", e.g. ML modules with abstract
members, or non-exported data constructors in Haskell. Another option would be
simply closing over whatever you're trying to hide. Another option would be
existential types. (There's some overlap among all of these.)

Composition... well, actually I'm not sure what exactly you mean by
"composition" in the context of OO. Can you explain what you mean?

~~~
catnaroek
> ML modules with abstract members

So true! Sadly, most programmers' idea of an “abstract data type” is a class.
:-p

~~~
lomnakkus
Booyakasha! :)

------
geodel
Interesting interview. Java is mentioned many times as language Swift aspires
to replace. He is right about Kotlin:

"Kotlin is very reference semantics, itʼs a thin layer on top of Java, and so
it perpetuates through a lot of the Javaisms in its model.

If we had done an analog to that for Objective-C it would be like, everything
is an NSObject and itʼs objc_msgSend everywhere, just with parentheses instead
of square brackets. .."

I think Swift has real chance to reach Java level popularity. It is already at
#11 in Redmonk ranking. All languages above Swift are at least 15 year older
than Swift. And once it server side features like concurrency it can be much
more general purpose.

~~~
gurkendoktor
I wish Swift focused on reference semantics. One of the big problems of value
types in C++ is that you have to be a language lawyer to not accidentally make
wasteful copies of everything, and the same is true of Swift:

[http://rosslebeau.com/2016/swift-copy-write-psa-mutating-
dic...](http://rosslebeau.com/2016/swift-copy-write-psa-mutating-dictionary-
entries)

I thought Objective-C had already solved this problem quite nicely with the
explicit NSFoo/NSMutableFoo class pairs. I don't see why this needed to be
fixed again, in a less explicit way.

~~~
bushin
They are trying to address that
[https://github.com/apple/swift/blob/master/docs/OwnershipMan...](https://github.com/apple/swift/blob/master/docs/OwnershipManifesto.md)

------
hellofunk
Wow, he just really really does not like C++. He is certainly an extremely
knowledgeable C++ guy, obviously Swift is written in C++, but it's hard to
entirely agree with his opinion on it across all fronts.

~~~
valuearb
As someone who spent over 20 years writing applications in C, anything built
on C is crap and that includes C++ and Objective C.

Writing code is fun and interesting. But most software development is not
writing code. It's a little bit of build management, even more testing, but
mostly it's debugging. Debugging is not as fun as writing code. Every language
feature that makes debugging more necessary, harder to do and more time
intensive sucks. Dangling pointers are the absolute worst.

I can easily give up multiple inheritance for a more functional language
that's far easier to write correct code in.

~~~
KKKKkkkk1
With Valgrind, I would say dangling pointers are a solved problem by now. The
real debugging headaches in C++ come from stuff like autogenerated
constructors, overloading, template specialization, and other features that
change semantics without requiring the syntax of the code that experiences the
change to reflect that change. My unpopular opinion is that exceptions also
fall into this class of dark features.

~~~
comex
> With Valgrind, I would say dangling pointers are a solved problem by now.

Given the frequency with which use-after-free vulnerabilities are discovered
in C++ programs, I’d say they’re not a solved problem. Valgrind is great but
it doesn’t help when the only inputs that cause bad behavior are bizarre
attacker-generated ones.

------
coldtea
> _Look at Javascript or any of these other languages out there. They started
> with a simple premise (“I want to do simple scripting in a web browser”) and
> now people are writing freaking server apps in it. What happened there? Is
> there a logical leap that was missed? How is this a good idea? [Audience
> laughs] Sorry, I love Javascript too. Iʼd just love to kill it even more._

Emphasis mine. Not that I disagree completely...

~~~
draw_down
It's interesting to see people talk a bunch about how nothing is good or bad,
it's all a bunch of trade offs, and then they eventually tip their hand. I
think people should just come out and say what they think is good or bad.

------
anshargal
I think that very important aspect of achieving world domination for Swift is
front-end development for Web (with compiler targeting JS or Web Assembly)

In a way many iOS and macOS applications are front-end software. It much more
makes sense to make Swift available for other kinds of front-end development
that for server-side coding.

~~~
alper
That's the most curious part, that he wants to go more low-level with Swift
instead of high-level.

Systems programming seems well catered for with Java, Go and Rust while high
level application programming is left at the mercy of javascript (I like
TypeScript but it's mostly improvements borrowed from C# that are bolted on).
I think there would be a lot to gain there first and foremost by compiling
Swift to WebAssembly.

------
milansuk
> My goal for Swift has always been and still is total world domination

I hope that this is never happen. Swift is great, it's universal and it saves
you a lot of time during coding, BUT It also has very large syntax and high
number of features - documentation is huge! The most of swift programmers
probably don't know complete syntax and all features which is problem in a
world where we code in teams and work with open source(both cases mean that
you work with code you didn't write).

We just need new simple way how billions of people can explain computers what
to do and backwards understand what computer was told to do and I'm sure that
it's not Swift, Java or C++.

~~~
valuearb
That feature size is why Swift is so scalable. Writing useful programs is easy
to do for beginners with a very limited subset of the language. But as you
expand your knowledge Swift is rich with features that make complex apps much
easier to write for professionals.

~~~
gurkendoktor
Many features only exist because Swift needs to work inside an ecosystem built
on Objective-C. Otherwise, would we really have both "static" and "class"
methods? Or Swift's method declaration/call syntax that looks unlike anything
else (except maybe Objective-C)?

I love Objective-C, but I don't want to inherit its baggage (via Swift) when I
write backend code.

~~~
plorkyeran
While Swift's use of argument labels would probably never have existed without
the Objective-C legacy, they're pretty much the last thing I'd point to as
"baggage". The Swift 1.x version of them was kinda weird, but now that the
rough edges have been fixed I'd consider the optional named parameters one of
the strengths of the languages.

I really can't think of anything in Swift 4 that exists in the subset of the
language supported on Linux which is there for obj-c reasons that I would
consider an actual problem.

~~~
gurkendoktor
I am a big fan of named arguments. But Swift has both argument labels _and_
argument names, and I don't see the point, other than for ObjC compatibility.
I find Kotlin's approach conceptually nicer, where parameter names and labels
are the same thing.

To give an example (possibly a particularly bad one),
UIView.bringSubview(toFront view: UIView) - I feel that the argument label has
made it harder, not easier, to give this method a good name.

------
draw_down
More shitting on JS. It's ok though.

------
valuearb
BTW: Before we get too deep in specific language criticisms, let's not forget
that Chris Lattner is awesome. The fact that two super smart guys with huge
work ethics like Chris and Elon Musk couldn't get along is very disappointing
to me.

~~~
pavlov
Was Lattner the right person to run the Tesla Autopilot development program?
Spending seven years perfecting a programming language is a very different --
and relatively serene -- job compared to putting together the mythical
ML/heuristics package that will prevent people from dying in self-driving
Teslas, and making it happen yesterday.

~~~
valuearb
Yes he was, because it's a software problem and he's proven himself to be
world class at solving software problems. Here is some more evidence from his
resume.

"When I joined Tesla, it was in the midst of a hardware transition from
"Hardware 1" Autopilot (based primarily on MobileEye for vision processing) to
"Hardware 2", which uses an in-house designed TeslaVision stack. The team was
facing many tough challenges given the nature of the transition. My primary
contributions over these fast five months were:

We evolved Autopilot for HW2 from its first early release (which had few
capabilities and was limited to 45mph on highways) to effectively parity with
HW1, and surpassing it in some ways (e.g. silky smooth control). This required
building and shipping numerous features for HW2, including: support for local
roads, Parallel Autopark, High Speed Autosteer, Summon, Lane Departure
Warning, Automatic Lane Change, Low Speed AEB, Full Speed Autosteer, Pedal
Misapplication Mitigation, Auto High Beams, Side Collision Avoidance, Full
Speed AEB, Perpendicular Autopark, and 'silky smooth' performance. This was
done by shipping a total of 7 major feature releases, as well as numerous
minor releases to support factory, service, and other narrow markets. One of
Tesla's huge advantages in the autonomous driving space is that it has tens of
thousands of cars already on the road. We built infrastructure to take
advantage of this, allowing the collection of image and video data from this
fleet, as well as building big data infrastructure in the cloud to process and
use it. I defined and drove the feature roadmap, drove the technical
architecture for future features, and managed the implementation for the next
exciting features to come. I advocated for and drove a major rewrite of the
deep net architecture in the vision stack, leading to significantly better
precision, recall, and inference performance. I ended up growing the Autopilot
Software team by over 50%. I personally interviewed most of the accepted
candidates. I improved internal infrastructure and processes that I cannot go
into detail about. I was closely involved with others in the broader Autopilot
program, including future hardware support, legal, homologation, regulatory,
marketing, etc. Overall I learned a lot, worked hard, met a lot of great
people, and had a lot of fun. I'm still a firm believer in Tesla, its mission,
and the exceptional Autopilot team: I wish them well."

[http://nondot.org/sabre/Resume.html](http://nondot.org/sabre/Resume.html)

~~~
pavlov
Not all software problems are the same, and many of them are primarily
management problems.

~~~
valuearb
Which is good, because he's been primarily a manager for the last decade.

~~~
pavlov
Not all management problems are the same. Which brings us back to my original
comment: maybe Swift and Autopilot are very, very different projects.

------
dgfgfdagasdfgfa
Could someone explain why I should build a language developed entirely by and
for writing Apple ecosystem products? It seems like if I'm not targeting MacOS
or iOS directly, the long list of benefits suddenly looks much, much smaller
compared to e.g. JVM, .NET, Go, etc etc.

"letʼs start hacking, letʼs start building something, letʼs see where it goes
pulling on the string" feels scarily accurate, and it's unclear where the
language will be in 5 years.

Among other things, there's no way to disable objective-c interop, even though
it complicates the language and feels like someone merged smalltalk, C++, and
ML—not a pretty combination. But—literally the only reason you'd enable that
would be to work with Cocoa/UIKit.

I'm still out on ARC—it was much less of a problem than I expected on my last
project, but it never feels like an optimal solution, and you can never just
"forget about it for the first draft" the way you can a VM's GC.

~~~
LeoNatan25
> a language developed entirely by and for writing Apple ecosystem products

So, apparently you didn't even read the article, as it is explicitly stated
that this was not the intention or direction of Swift.

> Among other things, there's no way to disable objective-c interop, even
> though it complicates the language and feels like someone merged smalltalk,
> C++, and ML—not a pretty combination. But—literally the only reason you'd
> enable that would be to work with Cocoa/UIKit.

Swift on Linux does not use any of the ObjC runtime features that are used on
Apple platforms.

~~~
wulfklaue
> So, apparently you didn't even read the article, as it is explicitly stated
> that this was not the intention or direction of Swift.

It might actually help that there is a real commitment in that direction. The
issue being that it was IBM that mostly pushed for changes in foundation and
without there initial blue socket support, even the most basic tasks did not
even succeed.

Let alone the none existing windows support. It may not have been Chris his
intention but one now ex-employee intention does not mean a lot when the
company determines the direction after his release.

~~~
LeoNatan25
While I agree that the state of the Foundation frameworks should be better, I
would not go as far as saying Apple is disinterested. Just lower priority.
Also, seeing how Swift has evolved, the community has a very large impact on
the direct Swift is taking.

