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

31–40 of 120 posts

Re: Chris Lattner on the Realm WWDC 2017 Swift Panel

#31

Post by gurkendoktor »

valuearb wrote: post #5
milansuk wrote: post #3

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

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.

Re: Chris Lattner on the Realm WWDC 2017 Swift Panel

#32

Post by LeoNatan25 »

pjmlp wrote: post #29
LeoNatan25 wrote: post #15

Earlier quoted context omitted.

I have to wonder if pandering to "fresh college grad" only is the way forward with new languages. We were once beginners - did you see challenges when you were studying the languages you are now fluent in? I have a feeling like the computer world is being torn between two extremes - either go all-out complex or "think of the children" simple approach. Not just in programming languages, but in software development in…

In the old days we learned directly with a mix of BASIC and Z80 (or 6502) Assembly, at the age of 10. I was already doing C++ for MS-DOS while at the technical school (15-18 years old) and learned OOP via Turbo Pascal 5.5 and 6.0 before getting into C++. Just look at kids today doing C++ with Arduino at school with similar ages. So I really fail to understand the whole pandering "fresh college grad" concept.

> fresh college grad

I think the point is to bring in as much cheap[er] labor as possible. I mean, obviously people have been managing to cope with complex languages in complex multi-hundred and multi-million lines of code for decades, but now, with the startup craze, there is a need for a vast amount of developer force, that may not be as capable as before. When people go into the business for money reasons alone, things get bleak. I think that concept is for these people. And I get it, money is important! But I think there should be at least some passion there there too, and that's not just for software development, but for most walks of life.

Re: Chris Lattner on the Realm WWDC 2017 Swift Panel

#33

Post by kornish »

LeoNatan25 wrote: post #22
kornish wrote: post #17

Earlier quoted context omitted.

Don't get me wrong, Go's simplicity comes with considerable tradeoffs and I'm not sure I'd use it in most cases again (started a greenfield codebase with it 3 years ago which is now around 200kloc). Just pointing out that syntactic edge cases can make writing easy, but most of programming (beyond one-off scripts) isn't writing. See: Scala and C++. Companies using these languages in production frequently disallow enti…

As I said in another comment, there seems to be a battle between extremes. On one end, the "complex" C++, Scala and others. On the other, simplistic stuff, such as JavaScript, Go, etc. It's probably gross injustice to put Go and JS in the same category, so I apologize, but for this argument, let's over look it. I think Swift and Rust are a good middle ground here. With your large project, in hindsight would you prefe…

I think I lean the same way as you: the option for complexity, and counting on static analysis/linters/discipline to bound that complexity.

That said, for all its theoretical flaws, Go is certainly a productive language (and has grown a pretty handy ecosystem over the years). In the end, the project was deemed a success and choice of language probably played a minimal role compared to hiring good people and prioritizing the right features.

Re: Chris Lattner on the Realm WWDC 2017 Swift Panel

#34

Post by LeoNatan25 »

pjmlp wrote: post #20
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…

For that to happen Swift needs to be usable at Java level in all OSes where JVM/JDKs (some of them with AOT support since the early days of Java) do exist. I am still waiting for first class support on Windows on the download page. Right now Rust has much better OS support than Swift.

At the timeframe discussed on the panel, I don't think Swift is really lagging. In few years, it has gone rather well, and in few more years, it should mature a lot more on multiple platforms. Right now, I think attempting to use Swift on a Linux server would be a big nuisance; it's enough to look at the open-source implementation of Foundation & co. and the many trivial things still missing. Once that is complete, it should start becoming more interesting. I don't think the push for Windows support will be very difficult.

Re: Chris Lattner on the Realm WWDC 2017 Swift Panel

#35

Post by dyarosla »

soulbadguy wrote: post #16
legulere wrote: post #11

Earlier quoted context omitted.

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.

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

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-cleanly work within an OOP design, but you'll find that it's often the case that a lot of verbosity needs to come along for the ride- working towards solving how to structure class hierarchies more than solving the actual problems those classes are meant to solve.

There's a reason why composition is preferred over inheritance. There's also good reason why some programmers will take it to the extreme and say that it ALWAYS causes more problems. Some languages lack of providing an appropriate aggregation alternative generally keeps inheritance alive.

Some people will hold onto their positive notions about inheritance too, and that's fine, but there's a reason why many people advocate strongly against it (and why some modern language designers skip it altogether!)

Re: Chris Lattner on the Realm WWDC 2017 Swift Panel

#36

Post by LeoNatan25 »

dgfgfdagasdfgfa wrote: post #19

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

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

Re: Chris Lattner on the Realm WWDC 2017 Swift Panel

#37

Post by gurkendoktor »

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 needed to be fixed again, in a less explicit way.

Re: Chris Lattner on the Realm WWDC 2017 Swift Panel

#38

Post by bushin »

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…

Reminds me of PHP CEO's tweet: "If you had bad experiences with scrum you just did scrum wrong. If you had good experiences making software you just accidentally did scrum".

Re: Chris Lattner on the Realm WWDC 2017 Swift Panel

#39

Post by rimliu »

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.

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

Re: Chris Lattner on the Realm WWDC 2017 Swift Panel

#40

Post by euyyn »

dyarosla wrote: post #35
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…

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

Post reply on HN