Live data from Hacker News

Chris Lattner on the Realm WWDC 2017 Swift Panel

oleb.net

111–120 of 120 posts

Re: Chris Lattner on the Realm WWDC 2017 Swift Panel

#111
post #110

Earlier quoted context omitted.

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.

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

Re: Chris Lattner on the Realm WWDC 2017 Swift Panel

#112
post #56
post #39

Earlier quoted context omitted.

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?

Static methods are final, class methods are not.

Re: Chris Lattner on the Realm WWDC 2017 Swift Panel

#113
post #56

Earlier quoted context omitted.

So why not just static methods, then?

Static methods are final, class methods are not.

I was responding specifically to the argument that you can't have only class methods because not everything is a class, in which case you could just call them something else other than "class method".

Re: Chris Lattner on the Realm WWDC 2017 Swift Panel

#114
post #70

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

> most C code still is correct C++ code Syntaxicaly yes, but with a more precise semantic and clearer stated "undefined behavior". The canonical example is the work around type punning and such.

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

Speed is only one part of the equation. For stuff like drivers and low level embedded development, we still needs C like unsafe memory manipulation. Rust,D,C# etc all have ways to do that.

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

Let's just agree to disagree on that one

Re: Chris Lattner on the Realm WWDC 2017 Swift Panel

#115
post #110

Earlier quoted context omitted.

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

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

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

Re: Chris Lattner on the Realm WWDC 2017 Swift Panel

#116

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

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

Re: Chris Lattner on the Realm WWDC 2017 Swift Panel

#117

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.

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.

Re: Chris Lattner on the Realm WWDC 2017 Swift Panel

#118

Earlier quoted context omitted.

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

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

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.

Re: Chris Lattner on the Realm WWDC 2017 Swift Panel

#119

Earlier quoted context omitted.

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.

Uh, how does that relate to the semantics of the language? (Formally, not dictionarily.)

EDIT: I was being a bit facetious, but we were discussing programming languages, so maybe not that much of a stretch...?

Re: Chris Lattner on the Realm WWDC 2017 Swift Panel

#120

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…

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

Booyakasha! :)
Post reply on HN