13 ms·

Chris Lattner on the Realm WWDC 2017 Swift Panel

121 points by king7532 9y ago

hellofunk 9y ago
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.
- valuearb 9y ago
  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 more time intensive sucks. Dangling pointers are the absolute worst. I can easily give up multiple inheritance for a more functional language that's far easier to write correct code in.
  - soulbadguy 9y ago
    > 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 intensive sucks. Dangling pointers are the absolute worst. language design is an exercise in compromise, and there is space for multiple compromise points on the spectrum. C++ decided (for better or for worst) to go for performance vs nice debugging experience. > I can easily give up multiple inheritance for a more functional language that's far easier to write correct code in. Am i the only getting tired of this kind of blanket statements ?
    - _ph_ 9y ago
      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)
      - soulbadguy 9y ago
        > 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
  - gurkendoktor 9y ago
    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.)
    - LeoNatan25 9y ago
      Apparently, the elegance of ObjC's handling of nil objects is considered also "unsafe" these days. I disagree with that specifically.
      - favorited 9y ago
        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 <= 10.4, - when expecting a returned `long long` on PPC (it happened to return `(long)selector`) 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.
    - pjmlp 9y ago
      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.
  - KKKKkkkk1 9y ago
    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.
    - comex 9y ago
      > With Valgrind, I would say dangling pointers are a solved problem by now. Given the frequency with which use-after-free vulnerabilities are discovered in C++ programs, I’d say they’re not a solved problem. Valgrind is great but it doesn’t help when the only inputs that cause bad behavior are bizarre attacker-generated ones.
    - pjmlp 9y ago
      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.
  - Akira1364 9y ago
    TFW you code in Object Pascal and don't have C-trubz
- pjmlp 9y ago
  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 those tasks, where those better languages cannot properly fulfil them. But as the CVE database proves, it only works if everyone on the team cares about safety, otherwise it is a lost game, only fixable by preventing everyone on the team to write C style unsafe code to start with. Sure nowadays there are plenty of analysers to ensure code safety, but they work mostly on source code and like any tool, suffer from people really caring to use them.
  - duneroadrunner 9y ago
    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-AutoTranslation https://github.com/duneroadrunner/SaferCPlusPlus-AutoTransla...
- coldtea 9y ago
  >He is certainly an extremely knowledgeable C++ guy, obviously Swift is written in C++ Well, he has written not just LLVM in C++, but also a C++ compiler in it (Clang), besides having written Swift in C++. So that's as far as knowing C++ one can go I'd say.
milansuk 9y ago
> 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 open source(both cases mean that you work with code you didn't write). We just need new simple way how billions of people can explain computers what to do and backwards understand what computer was told to do and I'm sure that it's not Swift, Java or C++.
- valuearb 9y ago
  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.
  - kornish 9y ago
    I don't think the problem with a large syntax is for writing - it's for reading. What happens when those same beginners are thrust into a professional production codebase and struggle to figure out what's going on? It's interesting to note that Google has taken the deliberately opposite approach with Go: small syntax, learn 90% of the language's ins-and-outs in a few weeks, so that the average fresh college grad Googler (average tenure being less than 2 years, IIRC) spends as little time as possible ramping up and has relatively predictable output.
    - valuearb 9y ago
      There is some truth to what you are saying. I'm not a beginner so I probably can't appreciate how hard it is to learn new syntactical features. My experience is I've found it pretty easy to learn new ones from my peer's code, but I struggle with actually forcing myself to teach myself new and more complex language features when the existing ones work so well for me. I'd say Swift is probably harder to learn than it could be because of how much syntax for common features has changed over major releases.
valuearb 9y ago
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.
- deleted 9y ago
  [deleted]
- deleted 9y ago
  [deleted]
- AceJohnny2 9y ago
  > 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. I'm storing popcorn for the day all the people who've been burned working for Musk finally come together and speak out about his insanity as a manager. I suspect the thing holding them back is that Musk's goals are laudable and everyone still wants them to succeed. But be glad you're a (potential?) customer of Musk's, not an employee.
- pavlov 9y ago
  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.
  - valuearb 9y ago
    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 http://nondot.org/sabre/Resume.html
geodel 9y ago
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 brackets. .." I think Swift has real chance to reach Java level popularity. It is already at #11 in Redmonk ranking. All languages above Swift are at least 15 year older than Swift. And once it server side features like concurrency it can be much more general purpose.
- pjmlp 9y ago
  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.
  - LeoNatan25 9y ago
    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.
    - Duckton 9y ago
      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.
smaili 9y ago
> 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
- legulere 9y ago
  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.
  - soulbadguy 9y ago
    > 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 many programming languages only have inheritance based OOP in their toolbox. Do you have any objective way to measure that ? > Patterns like abstract visitor factories are hacks to express situations that cannot be expressed in an obvious way. But isnt that the reason to have a pattern ? An easy way to expression a non obvious recurring situation ?
    - lomnakkus 9y ago
      > 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're trying to hide. Another option would be existential types. (There's some overlap among all of these.) Composition... well, actually I'm not sure what exactly you mean by "composition" in the context of OO. Can you explain what you mean?
deleted 9y ago
[deleted]
dgfgfdagasdfgfa 9y ago
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 where the language will be in 5 years. 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. I'm still out on ARC—it was much less of a problem than I expected on my last project, but it never feels like an optimal solution, and you can never just "forget about it for the first draft" the way you can a VM's GC.
- LeoNatan25 9y ago
  > 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.
  - wulfklaue 9y ago
    > 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.
coldtea 9y ago
>Look at Javascript or any of these other languages out there. They started with a simple premise (“I want to do simple scripting in a web browser”) and now people are writing freaking server apps in it. What happened there? Is there a logical leap that was missed? How is this a good idea? [Audience laughs] Sorry, I love Javascript too. Iʼd just love to kill it even more. Emphasis mine. Not that I disagree completely...
- draw_down 9y ago
  It's interesting to see people talk a bunch about how nothing is good or bad, it's all a bunch of trade offs, and then they eventually tip their hand. I think people should just come out and say what they think is good or bad.
draw_down 9y ago
More shitting on JS. It's ok though.
anshargal 9y ago
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 9y ago
  [deleted]
- alper 9y ago
  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.

121 points by king7532 9y ago

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.

valuearb 9y ago
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 more time intensive sucks. Dangling pointers are the absolute worst. I can easily give up multiple inheritance for a more functional language that's far easier to write correct code in.
- soulbadguy 9y ago
  > 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 intensive sucks. Dangling pointers are the absolute worst. language design is an exercise in compromise, and there is space for multiple compromise points on the spectrum. C++ decided (for better or for worst) to go for performance vs nice debugging experience. > I can easily give up multiple inheritance for a more functional language that's far easier to write correct code in. Am i the only getting tired of this kind of blanket statements ?
  - _ph_ 9y ago
    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)
    - soulbadguy 9y ago
      > 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
- gurkendoktor 9y ago
  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.)
  - LeoNatan25 9y ago
    Apparently, the elegance of ObjC's handling of nil objects is considered also "unsafe" these days. I disagree with that specifically.
    - favorited 9y ago
      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 <= 10.4, - when expecting a returned `long long` on PPC (it happened to return `(long)selector`) 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.
  - pjmlp 9y ago
    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.
- KKKKkkkk1 9y ago
  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.
  - comex 9y ago
    > With Valgrind, I would say dangling pointers are a solved problem by now. Given the frequency with which use-after-free vulnerabilities are discovered in C++ programs, I’d say they’re not a solved problem. Valgrind is great but it doesn’t help when the only inputs that cause bad behavior are bizarre attacker-generated ones.
  - pjmlp 9y ago
    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.
- Akira1364 9y ago
  TFW you code in Object Pascal and don't have C-trubz
pjmlp 9y ago
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 those tasks, where those better languages cannot properly fulfil them. But as the CVE database proves, it only works if everyone on the team cares about safety, otherwise it is a lost game, only fixable by preventing everyone on the team to write C style unsafe code to start with. Sure nowadays there are plenty of analysers to ensure code safety, but they work mostly on source code and like any tool, suffer from people really caring to use them.
- duneroadrunner 9y ago
  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-AutoTranslation https://github.com/duneroadrunner/SaferCPlusPlus-AutoTransla...
coldtea 9y ago
>He is certainly an extremely knowledgeable C++ guy, obviously Swift is written in C++ Well, he has written not just LLVM in C++, but also a C++ compiler in it (Clang), besides having written Swift in C++. So that's as far as knowing C++ one can go I'd say.

milansuk 9y ago

> 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 open source(both cases mean that you work with code you didn't write). We just need new simple way how billions of people can explain computers what to do and backwards understand what computer was told to do and I'm sure that it's not Swift, Java or C++.

valuearb 9y ago
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.
- kornish 9y ago
  I don't think the problem with a large syntax is for writing - it's for reading. What happens when those same beginners are thrust into a professional production codebase and struggle to figure out what's going on? It's interesting to note that Google has taken the deliberately opposite approach with Go: small syntax, learn 90% of the language's ins-and-outs in a few weeks, so that the average fresh college grad Googler (average tenure being less than 2 years, IIRC) spends as little time as possible ramping up and has relatively predictable output.
  - valuearb 9y ago
    There is some truth to what you are saying. I'm not a beginner so I probably can't appreciate how hard it is to learn new syntactical features. My experience is I've found it pretty easy to learn new ones from my peer's code, but I struggle with actually forcing myself to teach myself new and more complex language features when the existing ones work so well for me. I'd say Swift is probably harder to learn than it could be because of how much syntax for common features has changed over major releases.

valuearb 9y ago

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.

deleted 9y ago
[deleted]
deleted 9y ago
[deleted]
AceJohnny2 9y ago
> 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. I'm storing popcorn for the day all the people who've been burned working for Musk finally come together and speak out about his insanity as a manager. I suspect the thing holding them back is that Musk's goals are laudable and everyone still wants them to succeed. But be glad you're a (potential?) customer of Musk's, not an employee.
pavlov 9y ago
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.
- valuearb 9y ago
  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 http://nondot.org/sabre/Resume.html

geodel 9y ago

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 brackets. .." I think Swift has real chance to reach Java level popularity. It is already at #11 in Redmonk ranking. All languages above Swift are at least 15 year older than Swift. And once it server side features like concurrency it can be much more general purpose.

pjmlp 9y ago
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.
- LeoNatan25 9y ago
  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.
  - Duckton 9y ago
    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.

smaili 9y ago

> 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

legulere 9y ago
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.
- soulbadguy 9y ago
  > 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 many programming languages only have inheritance based OOP in their toolbox. Do you have any objective way to measure that ? > Patterns like abstract visitor factories are hacks to express situations that cannot be expressed in an obvious way. But isnt that the reason to have a pattern ? An easy way to expression a non obvious recurring situation ?
  - lomnakkus 9y ago
    > 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're trying to hide. Another option would be existential types. (There's some overlap among all of these.) Composition... well, actually I'm not sure what exactly you mean by "composition" in the context of OO. Can you explain what you mean?

deleted 9y ago

[deleted]

dgfgfdagasdfgfa 9y ago

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 where the language will be in 5 years. 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. I'm still out on ARC—it was much less of a problem than I expected on my last project, but it never feels like an optimal solution, and you can never just "forget about it for the first draft" the way you can a VM's GC.

LeoNatan25 9y ago
> 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.
- wulfklaue 9y ago
  > 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.

coldtea 9y ago

>Look at Javascript or any of these other languages out there. They started with a simple premise (“I want to do simple scripting in a web browser”) and now people are writing freaking server apps in it. What happened there? Is there a logical leap that was missed? How is this a good idea? [Audience laughs] Sorry, I love Javascript too. Iʼd just love to kill it even more. Emphasis mine. Not that I disagree completely...

draw_down 9y ago
It's interesting to see people talk a bunch about how nothing is good or bad, it's all a bunch of trade offs, and then they eventually tip their hand. I think people should just come out and say what they think is good or bad.

draw_down 9y ago

More shitting on JS. It's ok though.

anshargal 9y ago

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 9y ago
[deleted]
alper 9y ago
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.