The first time I read through the swift manual. I thought to myself, "swift is Apples version of C++"<br><br>The book on c -- the C programming language by Brian kernighan -- is around 200 pages. <br><br>As for objective c I've yet to see a book that covers more than a single chapter Before diving into cocoa frameworks. <br><br>Big c++ was around 2000 pages, maybe more. Swift's book was around that size as well. It is huge...<br><br>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.<br><br>Swift may become modern day c++ <br><br><br><div class="gmail_quote"><div dir="ltr">On Sun, Feb 19, 2017 at 3:35 PM Dimitri Racordon via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Very interesting topic!<br class="gmail_msg">
<br class="gmail_msg">
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.<br class="gmail_msg">
<br class="gmail_msg">
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, …).<br class="gmail_msg">
<br class="gmail_msg">
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.<br class="gmail_msg">
<br class="gmail_msg">
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.<br class="gmail_msg">
<br class="gmail_msg">
Best regards,<br class="gmail_msg">
Dimitri<br class="gmail_msg">
<br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
</blockquote></div>