With Chris Lattner's move to Google and the state of Java it would interesting to see Google embrace Swift and add official support for it to Android.
From what I understand they’ve put their chips on Kotlin.
The fight of single platform gardens?
The Decade of Swift
91–100 of 145 posts
Re: The Decade of Swift
#92I like a lot about Swift: strong typing, good support for closures, reasonable abstractions. But there's a lot that I dislike too. A lot. In general, I find the language to be far too trendy and fussy. I get the impression the design was guided by the goal of streamlining snippets of code meant to highlight cool features, gaining undesirable complexity as a result. One example: Do we really need $n function parameter…
> Swift separates those inside and outside views, permitting different names for both. The named parameter handling is one of my favorite features of Swift. It makes Swift code self-documenting in a way most languages aren't.
I actually don't mind that feature too much. I do appreciate that it clarifies code with even a few arguments of the same type. Although there are other ways to clarify such situations in other languages. The Swift approach does lead to exceptionally verbose code, but that's obviously subjective.
It's the $n syntax that I think is overkill. Do we really need three different ways to name parameters?
Re: The Decade of Swift
#93I hate to say this, but Swift is to Objective-c, what Scala is to Java.... It was very exiting and promising at first, but it became bogged down due to its sheer run-away complexity and over-academic approach to programming.... To an outsider, or iOS new comer, Swift looks much better than Objective-c, (due to Objective-c weird syntax), but to many insiders, Swift seems like a huge missed opportunity... The use of Sw…
Can you go into any specifics? Personally I've found Swift to be incredibly easy to read and write, and that it largely delivers in terms of rolling out complexity through progressive disclosure. Most of the complexity is only there if you need it in my experience.
I keep hearing about this concept of "progressive disclosure", but I can't say I've seen it in Swift. Even the simplest functions I want to write, I tug on a little thread of an idea that I have, and pretty soon I'm pulling out this giant tangle that's got 3/4 of the Swift type system dangling off of it.
What you're saying may be technically true. My issue is with the "if you need it" part. Unfortunately, I don't get to choose what I think I need. The compiler does.
For example, every beginning Swift programmer runs into "Protocol can only be used as a generic constraint because it has Self or associatedType requirements" [1]. You start by thinking, I'm going to write a simple little type!, and then 30 seconds later you're digging through the least-documented parts of the Swift manual trying to figure out if there's a simple fix for this. (There isn't.) It's not like Objective-C where you write an -isEqualTo:(id) method and call it a day.
This happens all over the place. Swift lambdas are weirder than Objective-C blocks. Swift errors are weirder than Objective-C exceptions. Swift strings are weirder than Objective-C strings. Ultimately, there is always a reason for the complexity (often: performance), but the upshot is that for any Swift feature I've wanted to use, I always had to learn a lot of extra details before I was able to use it.
I feel there are a lot of other languages which are both easier to read and write, and do a much better job at progressive disclosure.
Re: The Decade of Swift
#94Earlier quoted context omitted.
There are worlds of software developers outside of the Startup sphere.
I’ve never worked at a startup. I know very few people who have been involved in the startup world. I have exclusively used C and C++ in my professional work (with a tiny bit of python for scripting). Yet I haven’t know anybody who primarily or even occasionally used C in their work for over a decade. I know they exist but the majority of C programmers moved on to C++ a long time ago. There are areas like kernel and…
Except the entire world runs on top of C and will continue to do so for quite some time, it's not all about new or user facing projects.
Linux is pretty popular.
Re: The Decade of Swift
#95Earlier quoted context omitted.
I’ve never worked at a startup. I know very few people who have been involved in the startup world. I have exclusively used C and C++ in my professional work (with a tiny bit of python for scripting). Yet I haven’t know anybody who primarily or even occasionally used C in their work for over a decade. I know they exist but the majority of C programmers moved on to C++ a long time ago. There are areas like kernel and…
Except the entire world runs on top of C and will continue to do so for quite some time, it's not all about new or user facing projects. Linux is pretty popular.
The world running on top of C and Linux being popular have nothing to do with this. Have you looked at what TIOBE claims to measure? They very specifically say it’s not about the number of lines of existing code. It’s supposed to be a measure of the popularity of the language.
From their site (https://www.tiobe.com/tiobe-index/):
“The TIOBE Programming Community index is an indicator of the popularity of programming languages. The index is updated once a month. The ratings are based on the number of skilled engineers world-wide, courses and third party vendors. Popular search engines such as Google, Bing, Yahoo!, Wikipedia, Amazon, YouTube and Baidu are used to calculate the ratings. It is important to note that the TIOBE index is not about the best programming language or the language in which most lines of code have been written.”
Re: The Decade of Swift
#96Earlier quoted context omitted.
I think Rust supersedes it in most aspects, especially in not being Apple driven.
I would kill for a language with Swift's productivity and usibility and Rust's tooling and ecosystem.
Rust can be quite usable and productive if you know the right shortcuts. The tradeoff is somewhat lowered performance (and Rust makes sure that you're aware of where you're choosing that tradeoff) but that's just the way it goes. It's not like Swift is any different.
Re: The Decade of Swift
#97Earlier quoted context omitted.
Swift is already a top 10 language according to TIOBE.
TIOBE’s methodology and rankings seem very dubious to me. When was the last time you met someone who primarily programs in C? (I was one of those people for 14 years, but that was a while ago). Red Monk seems much closer to reality: https://redmonk.com/sogrady/2019/07/18/language-rankings-6-1...
> When was the last time you met someone who primarily programs in C?
I am sorry to say, you live in a bubble.
Re: The Decade of Swift
#98Re: The Decade of Swift
#99Earlier quoted context omitted.
Can you go into any specifics? Personally I've found Swift to be incredibly easy to read and write, and that it largely delivers in terms of rolling out complexity through progressive disclosure. Most of the complexity is only there if you need it in my experience.
I keep hearing about this concept of "progressive disclosure", but I can't say I've seen it in Swift. Even the simplest functions I want to write, I tug on a little thread of an idea that I have, and pretty soon I'm pulling out this giant tangle that's got 3/4 of the Swift type system dangling off of it. What you're saying may be technically true . My issue is with the "if you need it" part. Unfortunately, I don't ge…
Interesting. I guess in my opinion, there is a difference between "swift has some pain points" and "swift is inherently over-complex". I have run into the associated types issue (which is improved a bit by the addition of existential by the way) but my reaction was more that this is a particular design pattern to avoid, rather than that the language is null and void.
Given that you've made the comparison to Objective-C, are you sure you're not just running up against the learning curve of a new language? There are cases where Swift is a bit stricter, and therefore it's harder to type code which will compile on the first try, but in many of those cases it's because the strictness is allowing you to avoid entire categories of runtime bugs, which would give a non-specific error in Objective-C given the dynamic nature of the language.
Re: The Decade of Swift
#100Earlier quoted context omitted.
TIOBE’s methodology and rankings seem very dubious to me. When was the last time you met someone who primarily programs in C? (I was one of those people for 14 years, but that was a while ago). Red Monk seems much closer to reality: https://redmonk.com/sogrady/2019/07/18/language-rankings-6-1...
> When was the last time you met someone who primarily programs in C? I am sorry to say, you live in a bubble.