Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Chris Lattner on the Realm WWDC 2017 Swift Panel

oleb.net

Post reply on HN
Print view View original

51–60 of 120 posts

Re: Chris Lattner on the Realm WWDC 2017 Swift Panel

#51

Post by dyarosla »

euyyn wrote: post #40
dyarosla wrote: post #35

Earlier quoted context omitted.

None of those things are necessarily fundamental notions in OOP so much as they are core constructs in many OOP languages. It's quite trivial to find multiple examples for why inheritance causes far more problems in many cases than when using composition- rigid class hierarchies and fragile superclasses are some such examples (problems: extendability/maintainability and high coupling). Patterns are ways to semi-clean…

> Some languages lack of providing an appropriate aggregation alternative generally keeps inheritance alive. I might not be understanding well, but are you talking of languages that happen to have no _composition_? But do have inheritance? Sounds like those with inheritance are a strict subset of those with composition (which in turn would be all but fringe languages).

No I'm talking about a lack of language constructs that make composition a pain and inheritance a quick fix: forwarding. Inheritance is often used improperly because writing forwarding methods to delegates is a pain. IS-A/HAS-A goes OUT-A the window: in many cases ushers developers to adopt it because it requires less typing.

Re: Chris Lattner on the Realm WWDC 2017 Swift Panel

#52

Post by favorited »

LeoNatan25 wrote: post #28
gurkendoktor wrote: post #25

Earlier quoted context omitted.

Avoiding dangling pointers requires a bit of discipline in pre-ARC Objective-C and C++, but now that we have ARC, isn't ObjC pretty much as safe as Swift? (Unless you explicitly use "assign" properties, of course.)

Apparently, the elegance of ObjC's handling of nil objects is considered also "unsafe" these days. I disagree with that specifically.

Objective-C's solution had its downsides, though. The classic `[firstName stringByAppendingString:lastName];` being fine when `firstName` is nil, but not if `lastName` is (though it doesn't always crash if `lastName` is nil – it's fine if `firstName is also nil!). Or how `[myObject isEqualTo:myObject]` returns false if `myObject` is nil. Or how adding a nil object to an NSArray doesn't crash (but is likely a bug!) when calling `arrayWithObjects:`, but does crash when it's an array literal.

These aren't world-ending problems, and you learn the rules easily enough, but it's like Objective-C only solved 1/2 of the problem.

Then there's the really strange corner cases, like how sending a message to nil was undefined behavior:

- when expecting a returned struct, before Apple switched to LLVM 3.0 (would vary depending on the platform's ABI, as well as the size of the struct) - when expecting a returned floating-point value on PPC For the record, I always loved how Objective-C handles this – I definitely preferred it to Java, Ruby, etc. where you're constantly checking for null or catching NPEs. But I like Swift's solution even more. I no longer have to remember about which parameters are nullable, or sanitize my inputs with `NSParameterAssert`s, etc.

Edit: also, `NSNull`. Ugh.

Re: Chris Lattner on the Realm WWDC 2017 Swift Panel

#53

Post by duneroadrunner »

pjmlp wrote: post #24
hellofunk wrote: post #2

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.

Many of us feel that way. We have a schizophrenic attitude towards C++. On one way we love the language, the expressive power it gives us, the type safety taken from Simula and Algol, thanks to C++'s type system. On the other hand like Chris puts it "has its own class of problems because itʼs built on the unsafety of C". So some of us tend to work around it, by using safer languages and only coming down to C++ for th…

It's still in early development, but there is a tool[1] that automatically converts potentially unsafe C/C++ code to be memory-safe. If the problem is C/C++ programmers that write unsafe code, rather than trying to change their practices (or even change the language they program in) maybe it's more practical to just have a robot "fix" the code.

[1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus-AutoTransla...

Re: Chris Lattner on the Realm WWDC 2017 Swift Panel

#54

Post by ridiculous_fish »

legulere wrote: post #45
soulbadguy wrote: post #16

Earlier quoted context omitted.

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

Aggregation and composition are almost the same, are not distinguished in e.g. Java and exist in pretty much every rogramming language regardless if they are object-oriented. Inheritance is presented everywhere as the go-to method for structuring everything in languages supporting inheritance. The whole java class library consists of huge class hierarchies. Every non-trivial java code base I have seen is heavily infe…

> Inheritance is presented everywhere as the go-to method for structuring everything in languages supporting inheritance. The whole java class library consists of huge class hierarchies.

That conclusion holds if your primary experience is Java: the Java class library is widely believed to have abused inheritance.

However other languages have avoided that trap. Apple's Cocoa frameworks in ObjC do use inheritance but also delegation, notifications, etc. Also Swift supports inheritance, but here we see Lattner describing inheritance as a "tool in our toolbox," not as the "go-to method for structuring everything."

> Inheritance is everything else but safe: you have to check if you broke the behavior of all methods and public fields you are inheriting.

Designing a class interface intended to be inherited is like any other API design exercise. Your API commits to invariants, and it's the client programmer's responsibility to follow them; if they do the class should not be broken.

If you find yourself checking "all methods and public fields," either the API is bad or you've misunderstood it.

Again, it's just one API design tool. Sometimes the alternative to inheritance is just an ad-hoc, bug-ridden re-implementation of inheritance.

Re: Chris Lattner on the Realm WWDC 2017 Swift Panel

#55

Post by vorg »

geodel wrote: 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…

> Kotlin is very reference semantics, itʼs a thin layer on top of Java

One of the main points of Kotlin is that it integrates tightly with IntelliJ. So Kotlin is a layer (not so thin) between a visual IDE (IntelliJ or Android Studio) and Java-decompilable bytecodes on the JVM.

You don't get that with other JVM languages, e.g. Apache Groovy only gives correct type hints in Eclipse 80% of the time, and JAD stopped working on Groovy-generated bytecodes in Groovy 1.7.

Re: Chris Lattner on the Realm WWDC 2017 Swift Panel

#56

Post by saghm »

rimliu wrote: post #39
gurkendoktor wrote: post #31

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.

Well, having 'class' method on struct or enum would look kind of weird, these are value objects, not classes.

So why not just static methods, then?

Re: Chris Lattner on the Realm WWDC 2017 Swift Panel

#57

Post by KKKKkkkk1 »

valuearb wrote: post #4
hellofunk wrote: post #2

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…

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.

Re: Chris Lattner on the Realm WWDC 2017 Swift Panel

#58

Post by catnaroek »

gurkendoktor wrote: post #37
geodel wrote: 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…

The conflation of values (which exist in the language's semantics on paper) with physical representations (which exist in computer memory) plagues most imperative languages that try to do value semantics.

Re: Chris Lattner on the Realm WWDC 2017 Swift Panel

#59

Post by catnaroek »

lomnakkus wrote: post #27
soulbadguy wrote: post #16

Earlier quoted context omitted.

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

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

> ML modules with abstract members

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

Re: Chris Lattner on the Realm WWDC 2017 Swift Panel

#60

Post by protomyth »

gurkendoktor wrote: post #31
valuearb wrote: post #5

Earlier quoted context omitted.

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.

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.

> Swift's method declaration/call syntax that looks unlike anything else (except maybe Objective-C)?

Well, Smalltalk actually, and Swift did a poor job of keeping it. Why everything has to look like C or Pascal is a mystery.

Swift makes Objective-C method calls like C with extra punctuation and people add classes to JavaScript. I wish Swift had at least respected that if anything just to cut down on punctuation.

Post reply on HN