A concern

Evolution Discussion
1

Hello All,

Its Sunday, time for some reflection...

One of the big plusses of Objective-C was that the entire manual was just a few pages long. I have not looked it up, but IIRC the entire manual describing the language was probably less than 50 pages. Much less if you subtract the filler stuff.

Now, Objective-C is -arguably- not a very ‘nice’ or aesthetically pleasing language.

Swift is a huge improvement aesthetically speaking. But at the cost of a much larger user manual. Right of the bat it was clear to me that in Swift some of the learning curve from the framework (Cocoa) was shifted into language (Swift). I.e. Swift seemed specifically targeted to the idioms we used in Objective-C/Cocoa. It was one of the reasons that I took to Swift immediately.

Now that we have Swift 3, many of the original shortcomings have been filled. A few remain, but imo not very many.

That brings me to my concern: Swift seems to be on course to become a behemoth of a language.

I am absolutely convinced that everybody on this list has the best of intentions. We all want the very best tool available. We want Swift to become a shiny many facetted jewel among the languages.

But in doing so we might -inadvertently- make Swift into a behemoth that can do everything ... if you know how!

In my opinion Swift is on course to become a very complex language where one needs guru status to be a mid level programmer. Beginning programmers will stand no chance whatsoever to maintain an app developed by an expert. (A bit like C++, another extremely powerful language - that seems to have been abandoned.)

I have been on this list now for a few weeks, and I see very little push-back on new suggestions. Most of the reactions are positive-constructive. IMO we need more push-back. Without it behemoth status is all but guaranteed.

I don’t know about the core team, I don’t know about Apple, I don’t know where they want to go.

I just want to make a plea here: Please stop Swift from becoming a behemoth.

I don’t know if the millions (?) of Swift developers not on this list agree with me. I somehow think they do, after all they are not on this list! They are not looking to change Swift...

Well, I just had to get that off my chest...

To close this off, I do want to take this opportunity to thank the core team for their work, I truly appreciate it!
And whatever may come, here is one happy Swift user!

Best regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: Balancingrock (Rien) · GitHub
Project: http://swiftfire.nl

2

I do not agree on his statement on Objective-C (if more people opted in to -Weverything, with very very few silenced warnings really, and treating warnings as errors would show how much opt in safety there is to be had), but I find the overall article interesting:

http://blog.cleancoder.com/uncle-bob/2017/01/11/TheDarkPath.html

···

Sent from my iPhone

On 19 Feb 2017, at 09:00, Rien via swift-evolution <swift-evolution@swift.org> wrote:

Hello All,

Its Sunday, time for some reflection...

One of the big plusses of Objective-C was that the entire manual was just a few pages long. I have not looked it up, but IIRC the entire manual describing the language was probably less than 50 pages. Much less if you subtract the filler stuff.

Now, Objective-C is -arguably- not a very ‘nice’ or aesthetically pleasing language.

Swift is a huge improvement aesthetically speaking. But at the cost of a much larger user manual. Right of the bat it was clear to me that in Swift some of the learning curve from the framework (Cocoa) was shifted into language (Swift). I.e. Swift seemed specifically targeted to the idioms we used in Objective-C/Cocoa. It was one of the reasons that I took to Swift immediately.

Now that we have Swift 3, many of the original shortcomings have been filled. A few remain, but imo not very many.

That brings me to my concern: Swift seems to be on course to become a behemoth of a language.

I am absolutely convinced that everybody on this list has the best of intentions. We all want the very best tool available. We want Swift to become a shiny many facetted jewel among the languages.

But in doing so we might -inadvertently- make Swift into a behemoth that can do everything ... if you know how!

In my opinion Swift is on course to become a very complex language where one needs guru status to be a mid level programmer. Beginning programmers will stand no chance whatsoever to maintain an app developed by an expert. (A bit like C++, another extremely powerful language - that seems to have been abandoned.)

I have been on this list now for a few weeks, and I see very little push-back on new suggestions. Most of the reactions are positive-constructive. IMO we need more push-back. Without it behemoth status is all but guaranteed.

I don’t know about the core team, I don’t know about Apple, I don’t know where they want to go.

I just want to make a plea here: Please stop Swift from becoming a behemoth.

I don’t know if the millions (?) of Swift developers not on this list agree with me. I somehow think they do, after all they are not on this list! They are not looking to change Swift...

Well, I just had to get that off my chest...

To close this off, I do want to take this opportunity to thank the core team for their work, I truly appreciate it!
And whatever may come, here is one happy Swift user!

Best regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: Balancingrock (Rien) · GitHub
Project: http://swiftfire.nl

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

3

Objective-C is a superset of C, and the C parts are really important in practice. Are you including the complexity of C in your measure?

-Chris

···

On Feb 19, 2017, at 1:00 AM, Rien via swift-evolution <swift-evolution@swift.org> wrote:

Hello All,

Its Sunday, time for some reflection...

One of the big plusses of Objective-C was that the entire manual was just a few pages long. I have not looked it up, but IIRC the entire manual describing the language was probably less than 50 pages. Much less if you subtract the filler stuff.

4

I think it’s intended but in a good way. If you have missed the podcast with Chris Lattner:

Podcast: ATP 205: People Don't Use the Weird Parts — Accidental Tech Podcast
Transcript: Episode 205: Chris Lattner Interview Transcript — Accidental Tech Podcast
Quote:

Obviously, I care a lot about Swift and I really want it to get to its goal of world domination.

···

--
Adrian Zubarev
Sent with Airmail

Am 19. Februar 2017 um 10:02:04, Rien via swift-evolution (swift-evolution@swift.org) schrieb:

Swift seems to be on course to become a behemoth of a language.

5

While you do have a valid point here, I, for one, would like to use a well-designed ‘behemoth’ language.
Also, I find the strive to achieve perfection (vis-a-vis stability) a refreshing point of view.
If I wanted a more conservative language I would stick with Java (or Objective-C).

-g.

6

Many developers classified Swift as a behemoth right when it was published, so it is a highly personal question wether a language is to complicated or to simple.
I guess there are two potential dangers:
People have different preferences, and Swift could try to make everyone happy: Using BEGIN/END or indentation as an alternative to braces would be such thing.
So far, Swift has kept the the claim of being opinionated, and I guess this won't change. We even saw things like tuple splat and currying being dropped…

Additionally, there is a certain aspect of different opinion that has much more potential for harm:
There are people who love rules and want to regulate as much as possible, and there are those with a more relaxed mindset.
The thing that is special about this pair of extremes is the way both groups tend to fight for their goals, because someone with a laissez-faire attitude won't fight at all, whereas the urge to control is a driving force of the other extreme.

So I'm sure that if the evolution process would be democratic, it would accumulate special cases and rules for them quickly — but we can keep the hope that those who decide about Swifts future are aware of the problem, and weight their decisions accordingly.
Right now, there is a debate about rolling back some changes with the access levels, and there was even a suggestion to remove all but two of them...

7

I definitely agree with you: simplicity is the ultimate sophistication. The way I see it, a great language should strive to be both full featured and simple: by reusing concepts and keywords whenever possible, by designing orthogonal features that work in concert to be even more powerful, by saying no to new features which don't add enough usefulness to be worth their cognitive weight.

We can definitely go too far in both directions: some languages are so simple they are very elegant, but miss features that would make them useful in more situations. Some other languages are so full featured that they become very powerful but are too complicated as a result: a mess to learn, implement and keep good at (C++ and D). Swift definitely tries to take a pragmatic approach, somewhere in between, perhaps slightly more on the full-featured side of things, but tries to reduce that cognitive load with progressive disclosure of features.

And I agree that we should continue to strive for keeping as much simplicity as is possible. That's why I'm fighting to get scoped-private access deprecated, and why I'm initially doubtful of features like "pure functions", even if that last case may provide enough advantage to be worth the cost. We should all strive to start discussing new features with initial scepticisme until we can prove tangible advantages.

Thanks for reminding us all of this :)

···

On 19 Feb 2017, at 10:00, Rien via swift-evolution <swift-evolution@swift.org> wrote:

Hello All,

Its Sunday, time for some reflection...

One of the big plusses of Objective-C was that the entire manual was just a few pages long. I have not looked it up, but IIRC the entire manual describing the language was probably less than 50 pages. Much less if you subtract the filler stuff.

Now, Objective-C is -arguably- not a very ‘nice’ or aesthetically pleasing language.

Swift is a huge improvement aesthetically speaking. But at the cost of a much larger user manual. Right of the bat it was clear to me that in Swift some of the learning curve from the framework (Cocoa) was shifted into language (Swift). I.e. Swift seemed specifically targeted to the idioms we used in Objective-C/Cocoa. It was one of the reasons that I took to Swift immediately.

Now that we have Swift 3, many of the original shortcomings have been filled. A few remain, but imo not very many.

That brings me to my concern: Swift seems to be on course to become a behemoth of a language.

I am absolutely convinced that everybody on this list has the best of intentions. We all want the very best tool available. We want Swift to become a shiny many facetted jewel among the languages.

But in doing so we might -inadvertently- make Swift into a behemoth that can do everything ... if you know how!

In my opinion Swift is on course to become a very complex language where one needs guru status to be a mid level programmer. Beginning programmers will stand no chance whatsoever to maintain an app developed by an expert. (A bit like C++, another extremely powerful language - that seems to have been abandoned.)

I have been on this list now for a few weeks, and I see very little push-back on new suggestions. Most of the reactions are positive-constructive. IMO we need more push-back. Without it behemoth status is all but guaranteed.

I don’t know about the core team, I don’t know about Apple, I don’t know where they want to go.

I just want to make a plea here: Please stop Swift from becoming a behemoth.

I don’t know if the millions (?) of Swift developers not on this list agree with me. I somehow think they do, after all they are not on this list! They are not looking to change Swift...

Well, I just had to get that off my chest...

To close this off, I do want to take this opportunity to thank the core team for their work, I truly appreciate it!
And whatever may come, here is one happy Swift user!

Best regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: Balancingrock (Rien) · GitHub
Project: http://swiftfire.nl

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

8

Hi,

Objective-C is a superset of C, the C11 standard is 683-pages long (OK, I'm talking about specification, not "user" guide). Everything that is part of C is part of Objective-C and might hurt the productivity of the developer at the worst moment: a sequence point breakage hidden in a macro, an integer overflow that get "optimized away", a strict aliasing breakage that produces surprising code... all those kinds of issues happen in real code when working with C and Objective-C. So, when you read the few pages of "getting started with" Objective-C you don't really know the language, you know the high-level principles.

Swift is much less surprising because of its focus not to have undefined behaviors: everything is well specified and just this makes the language much simpler to *really* master. There are some hard parts (memory management is still present and far from trivial. You need decades of programming to be a C / Objective-C expert, Swift is only 3 years old (in the wild), and I would suspect there is already a sensible amount of "experts" who understand the language.

I'm on the list since the beginning of the year, and what I see here is a list of proposals that tend to focus on making the language even more consistent and less surprising (access level consistency, better Int API, better String API, better enums, ...). That are rare cases where we are discussing new features of the language (like the ownership manifesto published at the end of the week), but this come to cover shortcomings of the languages (trade-offs that were made to have a language published earlier, but with a reduced feature set): in my point of view the lack of ownership, the lack of concurrency support, ... are shortcomings of the language that make working with Swift more surprising and that cause the need of "expert" developers when a full-featured consistent language may only require a "mid-level" programmer.

That said, whatever the language you chose, there will always be code written by "experts" who think it is important to write complex code to solve simple problems and that will not be accessible to beginners. I think having generics in a language is one of the key enablers of this kind of behavior: it becomes so easy to write meta-code. But at the same time, I will never consider generics bloat the language, because when well use they enable so many elegant use cases.

···

Le 19 févr. 2017 à 10:00, Rien via swift-evolution <swift-evolution@swift.org> a écrit :

Hello All,

Its Sunday, time for some reflection...

One of the big plusses of Objective-C was that the entire manual was just a few pages long. I have not looked it up, but IIRC the entire manual describing the language was probably less than 50 pages. Much less if you subtract the filler stuff.

Now, Objective-C is -arguably- not a very ‘nice’ or aesthetically pleasing language.

Swift is a huge improvement aesthetically speaking. But at the cost of a much larger user manual. Right of the bat it was clear to me that in Swift some of the learning curve from the framework (Cocoa) was shifted into language (Swift). I.e. Swift seemed specifically targeted to the idioms we used in Objective-C/Cocoa. It was one of the reasons that I took to Swift immediately.

Now that we have Swift 3, many of the original shortcomings have been filled. A few remain, but imo not very many.

That brings me to my concern: Swift seems to be on course to become a behemoth of a language.

I am absolutely convinced that everybody on this list has the best of intentions. We all want the very best tool available. We want Swift to become a shiny many facetted jewel among the languages.

But in doing so we might -inadvertently- make Swift into a behemoth that can do everything ... if you know how!

In my opinion Swift is on course to become a very complex language where one needs guru status to be a mid level programmer. Beginning programmers will stand no chance whatsoever to maintain an app developed by an expert. (A bit like C++, another extremely powerful language - that seems to have been abandoned.)

I have been on this list now for a few weeks, and I see very little push-back on new suggestions. Most of the reactions are positive-constructive. IMO we need more push-back. Without it behemoth status is all but guaranteed.

I don’t know about the core team, I don’t know about Apple, I don’t know where they want to go.

I just want to make a plea here: Please stop Swift from becoming a behemoth.

I don’t know if the millions (?) of Swift developers not on this list agree with me. I somehow think they do, after all they are not on this list! They are not looking to change Swift...

Well, I just had to get that off my chest...

To close this off, I do want to take this opportunity to thank the core team for their work, I truly appreciate it!
And whatever may come, here is one happy Swift user!

Best regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: Balancingrock (Rien) · GitHub
Project: http://swiftfire.nl

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

9

Interesting,

You are right somewhere, today following the swift evolution, mastering swift with the use of the new standard lib and Cocoa is time consuming, and request to dedicate serious resources.

I am not sure that the complexity come from the core language itself, it become complexe because of the interoperability with the low layer, think about Unsafe*Pointer stuff. And it would be difficult to make a point versus needs for powerful string capabilities, concurrency, expressivity... I love the support for functional programming style, conditional chaining... for exemple.

For sure almost thirty years ago I was a fan of ObjC versus C++ because of the Complexity gap. But at this time Foundation/Appkit was made of 32 class if I remember correctly ;)

Interesting that we discuss about that. There is always a need to limit entropy in coding :) Occam razor and KISS principles are worth to keep in mind.

Gérard

···

Le 19 févr. 2017 à 10:00, Rien via swift-evolution <swift-evolution@swift.org> a écrit :

Hello All,

Its Sunday, time for some reflection...

One of the big plusses of Objective-C was that the entire manual was just a few pages long. I have not looked it up, but IIRC the entire manual describing the language was probably less than 50 pages. Much less if you subtract the filler stuff.

Now, Objective-C is -arguably- not a very ‘nice’ or aesthetically pleasing language.

Swift is a huge improvement aesthetically speaking. But at the cost of a much larger user manual. Right of the bat it was clear to me that in Swift some of the learning curve from the framework (Cocoa) was shifted into language (Swift). I.e. Swift seemed specifically targeted to the idioms we used in Objective-C/Cocoa. It was one of the reasons that I took to Swift immediately.

Now that we have Swift 3, many of the original shortcomings have been filled. A few remain, but imo not very many.

That brings me to my concern: Swift seems to be on course to become a behemoth of a language.

I am absolutely convinced that everybody on this list has the best of intentions. We all want the very best tool available. We want Swift to become a shiny many facetted jewel among the languages.

But in doing so we might -inadvertently- make Swift into a behemoth that can do everything ... if you know how!

In my opinion Swift is on course to become a very complex language where one needs guru status to be a mid level programmer. Beginning programmers will stand no chance whatsoever to maintain an app developed by an expert. (A bit like C++, another extremely powerful language - that seems to have been abandoned.)

I have been on this list now for a few weeks, and I see very little push-back on new suggestions. Most of the reactions are positive-constructive. IMO we need more push-back. Without it behemoth status is all but guaranteed.

I don’t know about the core team, I don’t know about Apple, I don’t know where they want to go.

I just want to make a plea here: Please stop Swift from becoming a behemoth.

I don’t know if the millions (?) of Swift developers not on this list agree with me. I somehow think they do, after all they are not on this list! They are not looking to change Swift...

Well, I just had to get that off my chest...

To close this off, I do want to take this opportunity to thank the core team for their work, I truly appreciate it!
And whatever may come, here is one happy Swift user!

Best regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: Balancingrock (Rien) · GitHub
Project: http://swiftfire.nl

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

10

No, I was referring to the original Apple document that introduced Objective-C.

But actually C is a good example.

The original work by Ritchie and Kernighan was also quite limited in scope. A small book and could easily be learned in a WE, I think I still have it somewhere in my library...

Today -as you correctly point out- C has become, well, bloatware imo.

Partly because it had to grow with time (more hw architectures), but I think more so because of countless committee meetings…

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: Balancingrock (Rien) · GitHub
Project: http://swiftfire.nl

···

On 19 Feb 2017, at 18:55, Chris Lattner <clattner@nondot.org> wrote:

On Feb 19, 2017, at 1:00 AM, Rien via swift-evolution <swift-evolution@swift.org> wrote:

Hello All,

Its Sunday, time for some reflection...

One of the big plusses of Objective-C was that the entire manual was just a few pages long. I have not looked it up, but IIRC the entire manual describing the language was probably less than 50 pages. Much less if you subtract the filler stuff.

Objective-C is a superset of C, and the C parts are really important in practice. Are you including the complexity of C in your measure?

-Chris

11

Hello All,

Its Sunday, time for some reflection...

One of the big plusses of Objective-C was that the entire manual was just a few pages long. I have not looked it up, but IIRC the entire manual describing the language was probably less than 50 pages. Much less if you subtract the filler stuff.

If you add the size of the C specification, Objective-C is actually a very large language, with all kinds of quirks and undefined behavior. Most people coming to Objective-C already have some familiarity with C-like languages though, so I think this aspect is forgotten sometimes.

I have been on this list now for a few weeks, and I see very little push-back on new suggestions. Most of the reactions are positive-constructive. IMO we need more push-back. Without it behemoth status is all but guaranteed.

I don’t know about the core team, I don’t know about Apple, I don’t know where they want to go.

I think it is good and healthy that all kinds of outlandish ideas get discussed on this list; even if they never end up getting implemented — the discussions further mutual understanding and inspire better ideas in the future. It wouldn’t be productive for us to just unilaterally shut down such discussions.

Remember there’s a long road from “pitching an idea” to “core team accepts a proposal”. The bar for proposals accepted into Swift 4 is considerably higher; think of it as, “without this proposal, the language is fundamentally broken for an important use-case”.

Also I think one important quality of the Swift design is “progressive disclosure”. There are some advanced features, but they are layered on in such a way that one does not need to absorb most of them in order to be productive in the language. They can be learned over time. This is unlike, say, C++, where a lot of complexity has to be understood up-front before you can really write good modern C++.

It’s not necessarily a bad thing if a well-designed language with advanced features and a large standard library has a big manual.

I just want to make a plea here: Please stop Swift from becoming a behemoth.

As someone who admires small languages like Scheme, Smalltalk, Forth and ML, I can assure you that your point of view has its proponents here ;-) And I think the core team has very good taste when it comes to these things as well.

Slava

···

On Feb 19, 2017, at 1:00 AM, Rien via swift-evolution <swift-evolution@swift.org> wrote:

I don’t know if the millions (?) of Swift developers not on this list agree with me. I somehow think they do, after all they are not on this list! They are not looking to change Swift...

Well, I just had to get that off my chest...

To close this off, I do want to take this opportunity to thank the core team for their work, I truly appreciate it!
And whatever may come, here is one happy Swift user!

Best regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: Balancingrock (Rien) · GitHub
Project: http://swiftfire.nl

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

12

A couple people have pointed at least part of this out, but just to underline it:

"Objective-C" is able to be small only because it's sandwiched between C and Foundation, both of which are pretty big. A Swift book that discussed only non-generic classes and protocols without associated types would be pretty short, too.

···

On Feb 19, 2017, at 1:00 AM, Rien via swift-evolution <swift-evolution@swift.org> wrote:

One of the big plusses of Objective-C was that the entire manual was just a few pages long. I have not looked it up, but IIRC the entire manual describing the language was probably less than 50 pages. Much less if you subtract the filler stuff.

--
Brent Royal-Gordon
Architechies

13

The problem with keeping things simple is that it might become another
Java. Great for newbies, nightmare for seniors.

What you describe is rather bad practices within a team. I have very
positive experience with Scala (behemoth?) projects in a mixed
newbie/senior team. The key to success is a bit of training to the newbies
and very strict rules for everybody to follow.

I'm afraid we still lack to much in Swift as for today (i.e. good
functional capabilities) and if we stop thinking in a "behemoth" way we
never get em.

There is a big difference from one "behemoth" to another. I would compare
C++ and Scala. IMO C++ became a bad (fans forgive me, please) kind of
"behemoth" because of the legacy nobody wants to get rid of. Scala on the
other hand has an opposite approach: "we made a bad decision in the past...
screw it. Let's just reimplement it in a different way". As for me the
latter is the ONLY viable approach for complicated systems, including
"behemoth" languages.

···

On Sun, 19 Feb 2017 at 11:30 Georgios Moschovitis via swift-evolution < swift-evolution@swift.org> wrote:

While you do have a valid point here, I, for one, would like to use a
well-designed ‘behemoth’ language.
Also, I find the strive to achieve perfection (vis-a-vis stability) a
refreshing point of view.
If I wanted a more conservative language I would stick with Java (or
Objective-C).

-g.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

14

Very interesting topic!

I disagree with the premise. Without having written a single line of Objective-C (nor Cocoa), I was able to get started with Swift in maybe 2 busy nights. Advanced concepts are difficult to master, but imho the learning curve is not that steep.

There are experts in every languages used in the industry, because actual production-ready applications often required experts. That is not to say that all languages are born equal, but my belief is that if the complexity isn’t in the language, then it’s somehow pushed into the libraries. In that case, being an expert isn’t really about mastering the language, but rather about mastering all the intricacies of its mainstream libraries (J2EE, Ruby on Rails, the 10’000’000 libraries required to make something work in Javascript, …).

Now I do think it is indeed very important to be careful not to create another C++, and I would hate to see Swift going that way. Despite visible efforts to keep it at bay, the syntax of the language does look impressive, and the countless blog posts on capture semantics prove that memory management is not as intuitive as one would think. But judging by the few months I’ve been subscribed to this list, I don’t feel like the community (or at the very least the users of this list) is heading the way of an "12 years of experienced minimum required" behemoth. Additional keywords and syntactic constructions are often considered with a lot of prudence, and I’m under the impression that a solid 1/2 of the threads end up discussing about consistency at some points.

I find it very valuable to receive this great amount of suggestions, and I it’d be a little bit sad if everything was simply pushed-back in favour of conservatism. These suggestions, and following discussions, allow us to constantly reevaluate the consistency and ease-of-use of the language. This can be seen as most of the time people end up proposing extensions to existing types, or operator overloads.

Best regards,
Dimitri

15

I listened to this podcast, and it is fantastic - I’m going to listen to it again.

I used to have the same reservations about the directions that Swift was going in, but one thing Chris said in the podcast really changed my mind: the idea of progressively revealing complexity to the user.

At some level, if you want to do powerful things, you need to have powerful (and dangerous) tools. Since Chris’ goal for Swift is World Domination, it will eventually need to do everything. The important part is to do it in a measured way so that it’s easily approachable, yet you can peel back the complexity veils as you need to do more. That being said, I don’t think Swift has been doing a good job of this so far (String, Optionals, Generics) But I have faith that the community on swift-evolution, (with temperance from the core team) will eventually mould the language into the ideal: keep simple things simple, make difficult things easy, make impossible things possible. It would be nice if this were “written into the constitution” of Swift.

-Kenny

···

On Feb 19, 2017, at 1:24 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

I think it’s intended but in a good way. If you have missed the podcast with Chris Lattner:

Podcast: ATP 205: People Don't Use the Weird Parts — Accidental Tech Podcast
Transcript: Episode 205: Chris Lattner Interview Transcript — Accidental Tech Podcast
Quote:

Obviously, I care a lot about Swift and I really want it to get to its goal of world domination.

--
Adrian Zubarev
Sent with Airmail

Am 19. Februar 2017 um 10:02:04, Rien via swift-evolution (swift-evolution@swift.org <mailto:swift-evolution@swift.org>) schrieb:

Swift seems to be on course to become a behemoth of a language.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

16

The first time I read through the swift manual. I thought to myself, "swift
is Apples version of C++"

The book on c -- the C programming language by Brian kernighan -- is around
200 pages.

As for objective c I've yet to see a book that covers more than a single
chapter Before diving into cocoa frameworks.

Big c++ was around 2000 pages, maybe more. Swift's book was around that
size as well. It is huge...

Both are huge. Maybe the ability to be jack of all trades makes for a
dominant language. Kind of like English. It borrows from so many languages
but as a result has universal appeal.

Swift may become modern day c++

···

On Sun, Feb 19, 2017 at 3:35 PM Dimitri Racordon via swift-evolution < swift-evolution@swift.org> wrote:

Very interesting topic!

I disagree with the premise. Without having written a single line of
Objective-C (nor Cocoa), I was able to get started with Swift in maybe 2
busy nights. Advanced concepts are difficult to master, but imho the
learning curve is not that steep.

There are experts in every languages used in the industry, because actual
production-ready applications often required experts. That is not to say
that all languages are born equal, but my belief is that if the complexity
isn’t in the language, then it’s somehow pushed into the libraries. In that
case, being an expert isn’t really about mastering the language, but rather
about mastering all the intricacies of its mainstream libraries (J2EE, Ruby
on Rails, the 10’000’000 libraries required to make something work in
Javascript, …).

Now I do think it is indeed very important to be careful not to create
another C++, and I would hate to see Swift going that way. Despite visible
efforts to keep it at bay, the syntax of the language does look impressive,
and the countless blog posts on capture semantics prove that memory
management is not as intuitive as one would think. But judging by the few
months I’ve been subscribed to this list, I don’t feel like the community
(or at the very least the users of this list) is heading the way of an "12
years of experienced minimum required" behemoth. Additional keywords and
syntactic constructions are often considered with a lot of prudence, and
I’m under the impression that a solid 1/2 of the threads end up discussing
about consistency at some points.

I find it very valuable to receive this great amount of suggestions, and I
it’d be a little bit sad if everything was simply pushed-back in favour of
conservatism. These suggestions, and following discussions, allow us to
constantly reevaluate the consistency and ease-of-use of the language. This
can be seen as most of the time people end up proposing extensions to
existing types, or operator overloads.

Best regards,
Dimitri

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution