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.