GOPHERSPACE.DE - P H O X Y
gophering on hngopher.com
HN Gopher Feed (2017-06-30) - page 1 of 10
 
___________________________________________________________________
Chris Lattner on the Realm WWDC 2017 Swift Panel
58 points by king7532
https://oleb.net/blog/2017/06/chris-lattner-wwdc-swift-panel/
___________________________________________________________________
 
[deleted]
 
dgfgfdagasdfgfa - 31 minutes 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 - 2 minutes ago
  > a language developed entirely by and for writing Apple
  ecosystem productsSo, 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.
 
smaili - 1 hours 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 - 1 hours 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 - 38 minutes ago
    > The issues with inheritance based OOPInheritance 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 - 18 minutes 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?
 
      dyarosla - 4 minutes ago
      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!)
 
hellofunk - 2 hours 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.
 
  pjmlp - 21 minutes 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.
 
  valuearb - 1 hours 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 - 27 minutes 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 ?
 
    gurkendoktor - 19 minutes 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 - 16 minutes ago
      So, apparently, the elegance of ObjC's handling of nil
      objects is considered also "unsafe" these days. I disagree
      with that specifically.
 
milansuk - 2 hours ago
> My goal for Swift has always been and still is total world
dominationI 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 - 1 hours 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.
 
    gurkendoktor - 10 minutes ago
    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.
 
    kornish - 1 hours 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 - 1 hours 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.
 
        LeoNatan25 - 42 minutes ago
        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 general. If forced to pick out of
        those two, my personal preference would be the complex, but
        I would like to see a middle ground of "moderate"
        technologies.
 
          mikeash - 25 minutes ago
          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 work occurs.There is
          certainly a place for beginner-friendly languages. People
          need to learn to program at some point, and something
          which is aimed at helping them do that is really useful.
          But there's no reason that it should be the same language
          used by professionals to do real work.Imagine changing
          the design of a 747 to make it easier to fly for new
          pilots. We wouldn't dream of doing such a thing. The
          cockpit of a 747 is for experienced professionals. If
          you're learning to fly then you belong in the cockpit of
          something like a Cessna 152.Note that I'm not advocating
          for difficulty just for the sake of difficulty, and I
          don't want to keep people out. And if a language can
          accommodate beginners without making things worse for
          professionals then let's go for it. But it shouldn't be a
          major goal of most languages.
 
          LeoNatan25 - 19 minutes ago
          The cynic in me sees these approaches as a corporate-
          friendly way to be able to hire more "juniors" to save
          money. Entire frameworks and languages seemingly exist to
          enable low barrier entry to junior developers without any
          effort of the corporate to invest in these junior
          developers. There needs to be a balance between the need
          for junior developers to be productive and restricting
          technology just so as many as possible junior developers
          can be productive at low cost for the corporate. With
          stuff like React Native and Electron, I feel the former
          takes the lead at the expense of technology.Agree that
          simplistic languages could work well in academia, as the
          first language that students see. I studied C as my first
          language, and I am not sure that is optimal. Nor do I
          think Java is that language, as many study that first,
          these days.
 
          pjmlp - 14 minutes ago
          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.
 
          LeoNatan25 - 9 minutes ago
          > fresh college gradI 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.
 
      LeoNatan25 - 46 minutes ago
      Indeed, there is a debt to Go's
      simplicity:https://dave.cheney.net/2017/06/15/simplicity-debt
      https://dave.cheney.net/2017/06/18/simplicity-debt-reduxAnd
      slowly, the language is expanding in very obvious
      conclusions.Personally, I think there needs to be a balance
      in a language, where it should not be too restrictive in its
      syntax, but on the other hand, it should not be overly
      complex and has too much syntax. I am on the fence with
      Swift, but it does seem to come on the complex side.
 
        kornish - 36 minutes ago
        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 entire subsets of syntax or language features
        because they're hard to maintain.Balance certainly is key.
 
          LeoNatan25 - 26 minutes ago
          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 prefer Go or C++? At least with C++,
          you can go as complex as you want, or stop and set some
          "rules" that should not be passed. But I err on the side
          of having the option rather than being restricted.
 
          kornish - 6 minutes ago
          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 would
          have been among the least impactful choices we could have
          made. Hiring good people and prioritizing the right
          features proved much more important.
 
valuearb - 1 hours 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.
 
  AceJohnny2 - 11 minutes 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.
 
  [deleted]
 
  [deleted]
 
geodel - 1 hours 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 - 30 minutes 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 - 5 minutes 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.
 
  gurkendoktor - 1 minutes ago
  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.