Live data from Hacker News

Chris Lattner on the Realm WWDC 2017 Swift Panel

oleb.net

61–70 of 120 posts

Re: Chris Lattner on the Realm WWDC 2017 Swift Panel

#61
post #23

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…

I realize this is probably unpopular, but I personally think we shouldn't aim for beginner-friendliness in our production languages. If we can do it then fine, but it shouldn't come at the cost of anything else. People are only beginners for a (hopefully) short time, then they're not. Making things better for them in the post-beginner period is far more advantageous, since that's when the vast majority of productive…

It's a quandary. Beginner-friendliness does make a language somewhat easier to learn -- someone just trying to wrap their heads around the very idea of a program as a sequence of operations isn't going to appreciate being told that an integer is fundamentally different from a numeric string for reasons they don't yet understand (just to take one example).

Yet once someone has learned a language, they tend to keep using it. Their very inexperience prevents them from understanding that they should switch to something more industrial-strength once they start to write something larger and more complex. Plus, they don't even know when they start to write a program how big it is likely to get.

I don't know what to do about this except to continue to bang on the point you're making.

Re: Chris Lattner on the Realm WWDC 2017 Swift Panel

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

> BUT It also has very large syntax and high number of features

What realistic alternative playing in the same space doesn't have this problem?

Re: Chris Lattner on the Realm WWDC 2017 Swift Panel

#63
post #55
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 work…

Kotlin also happens to compile to JS and native code (using LLVM).

It's very wide use of lambdas with unique syntactic support for them makes it feel very different from Java.

Re: Chris Lattner on the Realm WWDC 2017 Swift Panel

#64
post #50

Earlier quoted context omitted.

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

I think attempting to use Swift on a Linux server would be a big nuisance I beg to differ. Look at Vapor, Kitura & Perfect. I know Foundation is missing implementations for Linux, but it is not something that makes it a big nuisance IMO. You can quickly have a setup with Swift on Linux running a simle CRUD app.

Yes it is possible and IBM is the one pushing for it.

However it is still light years behind JEE and Spring features, including parity with existing JDBC drivers.

Also besides instruments on OS X, there are no comparable performance monitoring tools like VisualVM, Mission Control and many others from the JDK vendors.

Re: Chris Lattner on the Realm WWDC 2017 Swift Panel

#65
post #4

Earlier quoted context omitted.

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.

Only on the platforms that support Valgrind, with teams that bother to use it.

Given that Apple, Microsoft and Google keep doing presentations about such tools at their conferences, and my experience at enterprise level, I would say not so many bother to use them.

Re: Chris Lattner on the Realm WWDC 2017 Swift Panel

#66
post #4

Earlier quoted context omitted.

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…

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

No because there is the whole C part of Objective-C, including UB.

So unless there is some validation of 100% of the code writen by the team and third party libraries, it is impossible to ensure there aren't C style coding tricks being used.

Also ARC only applies to Cocoa like classes, there is no bounds checking, implicit casts are like in C, C style strings are still used in many APIs, and this are just a few examples of unsafety.

Re: Chris Lattner on the Realm WWDC 2017 Swift Panel

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

Inheritance based OOP models tree-like entites well, where hirachy is defined and clear cut. Unfortunately, lots of real life domains are best expressed by graphs - commonly a DAG. You need to pay attention to your edges and not just the nodes. Inheritance based OOP gives you one keyword to express your edges: extend, and it's horribly inadequate. Mutatable state is not a issue in Java OOP, lacking the expressive power is.

Re: Chris Lattner on the Realm WWDC 2017 Swift Panel

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

Inheritance based OOP models tree-like entites well, where hirachy is defined and clear cut. Unfortunately, lots of real life domains are best expressed by graphs - commonly a DAG. You need to pay attention to your edges and not just the nodes. Inheritance based OOP gives you one keyword to express your edges: extend, and it's horribly inadequate. Mutatable state is not a issue in Java OOP, lacking the expressive power is.

Re: Chris Lattner on the Realm WWDC 2017 Swift Panel

#69

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…

> there's no way to disable objective-c interop Believe it or not, this compiler option is named `-disable-objc-interop`. > Could someone explain why I should build a language developed entirely by and for writing Apple ecosystem products? Possibly because you have an affinity for value types, performance, or safety. A language is a lot more than just a checkbox of platforms it supports, although iOS is a pretty larg…

> There is also a quasi-non-performance aspect to ARC that is often overlooked: deterministic deallocation.

Assuming there are no pauses due to deletion of deeply nested data structures, or worse, stack overflows.

Herb Sutter has a very interesting presentation at CppCon 2016 about these issues, where he then presents a kind of C++ library based GC to work around them.

Also ARC has performance impact, because increment/decrements need to be synchronized due to threaded code.

Re: Chris Lattner on the Realm WWDC 2017 Swift Panel

#70
post #4

Earlier quoted context omitted.

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…

> As someone who spent over 20 years writing applications in C, anything built on C is crap and that includes C++ and Objective C. Maybe that the problem, if you see C++ as something "built on C" then it logical that the see a lot of the same problem. C++ evolved from C to specifically address a lot of the weakness in C. > Every language feature that makes debugging more necessary, harder to do and more time intensiv…

The problem with C++ is, that for all its added complexity and powers, most C code still is correct C++ code, especially all the unsafe pointer manipulations. And there is no real performance reason. Many static typed languages compile to code as fast as C - if not faster thanks to tighter semantics. (Other than that some C compilers are better quality because of the effort went into them due to language popularity rather than any language feature)
Post reply on HN