Live data from Hacker News

Chris Lattner on the Realm WWDC 2017 Swift Panel

oleb.net

101–110 of 120 posts

Re: Chris Lattner on the Realm WWDC 2017 Swift Panel

#101
post #10

> 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

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.

[deleted]

Re: Chris Lattner on the Realm WWDC 2017 Swift Panel

#102

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.

[deleted]

Re: Chris Lattner on the Realm WWDC 2017 Swift Panel

#103

Earlier quoted context omitted.

> 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 say that as if these things are not just as easily expressed in FP No, that's what you read. What i said what was i wrote... OOP is bigger than inheritance. > -- if not even easier. Again, this kind of statement really sound like empty FP propaganda to me. > Encapsulation is just "abstract data types", e.g. ML modules with abstract members, or non-exported data constructors in Haskell. Another option would be s…

> No, that's what you read.

I think you may have misunderstood my intent. I was just trying to say "FP can do these things too".

> Again, this kind of statement really sound like empty FP propaganda to me.

Right, so any type of even very modest support for X is "empty X propaganda". Can we please assume at least a modicum of good faith here?

> Or "abstract data types" is just Encapsulation...

Oh, so "semantics" it is then. Oh, well.

FWIW, I think I'm right in saying that ADTs were invented quite a bit before OOP & "Encapsulation".

I notice that you also didn't answer my question of what Composition actually means in OOP. Do you have an answer? I promise, I wasn't being facetious.

Re: Chris Lattner on the Realm WWDC 2017 Swift Panel

#104

Earlier quoted context omitted.

> 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…

OOP is simply programming with objects. You can do that in a language of functions, you can also program with functions with a language of objects.

Define "objects", please.

Re: Chris Lattner on the Realm WWDC 2017 Swift Panel

#105
post #7

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…

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... I thought Objective-C had already solved this problem quite nicely with the explicit NSFoo/NSMutableFoo class pairs. I don't see why this…

> 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...

Not always. The C++ standard has allowed copy elision for some time [1]. Guaranteed copy elision for certain forms of copy has been proposed for C++17 [2].

[1] http://en.cppreference.com/w/cpp/language/copy_elision

[2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p013...

Re: Chris Lattner on the Realm WWDC 2017 Swift Panel

#106

Earlier quoted context omitted.

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.

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 lang…

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.

Re: Chris Lattner on the Realm WWDC 2017 Swift Panel

#107
post #85
post #6

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.

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.

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

Re: Chris Lattner on the Realm WWDC 2017 Swift Panel

#108

Earlier quoted context omitted.

OOP is simply programming with objects. You can do that in a language of functions, you can also program with functions with a language of objects.

Define "objects", please.

That's easy, the word is well defined in the dictionary: a person or thing to which a specified action or feeling is directed. Some people try to call objects entities and claim they are doing something else, but they are just doing the same thing with different words.

Re: Chris Lattner on the Realm WWDC 2017 Swift Panel

#109
post #4

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.

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…

TFW you code in Object Pascal and don't have C-trubz

Re: Chris Lattner on the Realm WWDC 2017 Swift Panel

#110
post #85

Earlier quoted context omitted.

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.

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 gi…

Not all software problems are the same, and many of them are primarily management problems.
Post reply on HN