4 ms·

Still trying to learn swift. My impression is that it’s an ugly language designed by committee (largeness and some extraneous features like guard) and part of t

by msie 4y ago

Still trying to learn swift. My impression is that it’s an ugly language designed by committee (largeness and some extraneous features like guard) and part of the reason why the compiler is slow and why xcode has problems with slow syntax checking sometimes.

danpalmer 4y ago
That's not really my impression at all. I see it as a fairly opinionated language that has taken a lot of inspiration from Ruby and Haskell. Things like strings are strongly opinionated and have gone through multiple revisions to get them to where they are. One of the opinions is that it values expressiveness, and having multiple ways to do things that means you can choose a nice way to express each line, rather than always being forced to write it the same way. This is a trade-off. To use `guard` as an example, sometimes it may be clearer to use a guard, and sometimes it may not. Swift has chosen to provide both options, at the cost of users needing to learn both. I think it developed a negative reputation for the fact that the first few iterations did have a lot of breaking changes and added a lot of features. This made sense to me, the first version was somewhat of an MVP and it needed plenty of work still, but the language is relatively mature now and has stabilised significantly in recent years. The compiler isn't generally that slow overall, but there are performance edge cases where complex type-checking can take far longer than other things. If you're having problems with speed, I'd recommend profiling your build, it's possible there are a handful of functions that are taking most of the build time.
- thewebcount 4y ago
  > If you're having problems with speed, I'd recommend profiling your build, it's possible there are a handful of functions that are taking most of the build time. How does one do that? I hit this problem a lot. (I’ve since learned to use lots of explicit casts to make it less bad.)
  - danpalmer 4y ago
    I can't remember exactly, it's been a year since I last did this. I believe there's a setting for the threshold at which this should be logged, so you could set it to log any expression that takes more than 100ms to type-check. By default I think it just times out at 10 seconds or something.
    - thewebcount 4y ago
      I looked into it, and found that you can add these "OTHER_SWIFT_FLAGS" to your project: OTHER_SWIFT_FLAGS = -Xfrontend -debug-time-expression-type-checking -Xfrontend -debug-time-function-bodies There's also this great WWDC session on build parallelization: https://developer.apple.com/wwdc22/110364 https://developer.apple.com/wwdc22/110364
- gary17the 4y ago
  > [Swift] values expressiveness, and having multiple ways to do things that means you can choose a nice way to express each line, rather than always being forced to write it the same way. There are at least two major problems with this kind of PL design approach: 1.) when you work on a large codebase from multiple contributors, all the possible combinations of the available syntax and standard library calls will eventually get used, making your brain frustrate quickly when reading code written by others, and 2.) when you interview for a new job, all the possible combinations of the available syntax and standard library calls will eventually be asked about by interviewers, making you look and feel like an incompetent programmer. I have to agree with the OP - Swift seems to be an unreasonably bloated PL. Unless one plans to work only with Swift all the time, learning all there is to learn about Swift on the way, it might be easier to just use Rust or Go.
  - dagmx 4y ago
    Rust and Swift have about the same amount of syntax imho, and often share a lot of it. Go is simpler as a language but you end up writing more code to accommodate that.
    - gary17the 4y ago
      > Rust and Swift have about the same amount of syntax I wouldn't agree, I feel Swift has significantly more surface area than Rust. But even syntax and standard libraries aside, I think that Rust is significantly more "explicit", "consistent" and "predictable" than Swift. I consider those to be very important qualities in a PL. Maybe that's why Rust was easier to learn and memorize than Swift (with the exception of the Rust borrow checker and lifetime annotations that indeed have to be well understood to be even usable). But it might be just me.
      - dagmx 4y ago
        Hmm can’t say I agree about the significantly more surface area. I switch between rust/C++/Swift fairly regularly for work, and I think they’re roughly similar in complexity with the exception of Rust having lifetime annotations and Swift having computer properties. Where I do think Swift has a lot of noise though is @attributes. There’s just so many attributes to learn, especially if you happen to do SwiftUI or ObjC interop. Though rust has the same issue , it’s just there’s no ubiquitous UI lib like SwiftUI. I imagine it would have the same if it did.
dagmx 4y ago
The things you find ugly are the things that I think make Swift code quite pleasant to work with. More languages need a guard. It’s a really great control flow operator to flatten your code. Rust added `let else` last year that does the same and it does wonders to clean up code. There are things I dislike about Swift , like lack of explicit namespace organization (rust mod or c++ namespace keywords, and the enum trick does not count) as well as the ability to drop extensions anywhere (which leads to a lot of stream of consciousness programming). However I don’t think I’d really consider it ugly. What languages are you coming from and what else do you not like about Swift?
- msie 4y ago
  Coming from the usual languages: pascal, modula-2, objective c, c, lisp, miranda, ruby, python. Another thing I don’t like about Swift are the named parameters which was an objective C thing. I find it makes reading code difficult because you don’t start parsing a function call until the first ‘(‘, you have to read the args too to determine which function is being called. I also don’t like the integration of swiftui syntax into swift. Plus you read some of the stuff going on in swift evolution and it seems they are hell bent on adding everything to the language.
  - dagmx 4y ago
    Personally (and totally subjectively) I’d argue that a lot of those languages you listed are ugly, with the exception of the last two. Some of them are nice looking for short bits but get really ugly for larger pieces of code. Especially when you practice defensive programming and are nested several levels deep because of the lack of optionals. The SwiftUI integration doesn’t materially change the language much. It’s based on passing in blocks as parameters and has been a norm for obj-c as well (effectively how everyone does completion handlers). But I think that’s why language beauty is in the eye of the beholder. To me, Swift allows flatter/cleaner code while defensively programming with lower branching and higher ergonomics. That’s beauty. That’s why guard is so nice. But I can see how it might be off putting if you’re coming from other PL paradigms. I think a lot of it comes down to whether people want simple syntax vs simple code. C for example is simple syntax but rarely ever simple code , Swift and rust are more complex syntax but much simpler code.
myko 4y ago
Surprised to see this opinion on `guard`! IMO it's such a nice feature for future developers looking at that code, it's a clear indicator to pay attention to this area of code and know exiting the function is important.
- msie 4y ago
  I may be too harsh on guard but I like small languages. When I first encountered guard I wondered if it was truly necessary to the language and it wasn't.
  - dagmx 4y ago
    Many languages have ergonomic features that aren’t truly necessary but are worth having. I recognize you prefer smaller languages but I’d like to make a case for guards usefulness. Guard is great because it’s a combined early return and assignment. Imho if you have a language with optionals, it’s a required pattern to have, or you end up with lots of conditional unwraps and nested blocks, or lots of placeholder variables that you might accidentally use in your code later causing safety or memory access issues . Take the following code if let foo = Some(optional) {yourLogicHere} else {return} That’s one level of nesting. Swift is nice enough to elide the Some matching so you’d just have if let foo = optional {yourLogicHere} else {return} Still one level of nesting but a little cleaner. Now if you have a language based around safety, like Rust or Swift, a lot of functions return optionals. So you’ll keep nesting code in your checks for safety Now take a guard. guard let foo = optional else { return } yourLogicHere That’s one level of unnesting removed , and that compounds. Better yet, you can chain them guard let foo = optional, let spam = foo.lookup() else {return} The equivalent in C like languages would be type foo; if (!getOptional(&foo) return; Now either you early return in the case of the optional failing or you nest. Nesting gets repetitive and deep. Or you unnest like I have and have that foo sticking around un-initialized, potentially causing issues of use later. Guard simultaneously removes both conundrums and makes your code both neater and safer.
    - O-stevns 4y ago
      Adding to this excellent explanation, the guard is compile time checked too, so you can't accidentally screw up the early return like one could in say c or c++ It might seem like a quality of life feature to some, to me however it's an essential feature of swift and one of the better ones.

by msie 4y ago

danpalmer 4y ago

That's not really my impression at all. I see it as a fairly opinionated language that has taken a lot of inspiration from Ruby and Haskell. Things like strings are strongly opinionated and have gone through multiple revisions to get them to where they are. One of the opinions is that it values expressiveness, and having multiple ways to do things that means you can choose a nice way to express each line, rather than always being forced to write it the same way. This is a trade-off. To use `guard` as an example, sometimes it may be clearer to use a guard, and sometimes it may not. Swift has chosen to provide both options, at the cost of users needing to learn both. I think it developed a negative reputation for the fact that the first few iterations did have a lot of breaking changes and added a lot of features. This made sense to me, the first version was somewhat of an MVP and it needed plenty of work still, but the language is relatively mature now and has stabilised significantly in recent years. The compiler isn't generally that slow overall, but there are performance edge cases where complex type-checking can take far longer than other things. If you're having problems with speed, I'd recommend profiling your build, it's possible there are a handful of functions that are taking most of the build time.

thewebcount 4y ago
> If you're having problems with speed, I'd recommend profiling your build, it's possible there are a handful of functions that are taking most of the build time. How does one do that? I hit this problem a lot. (I’ve since learned to use lots of explicit casts to make it less bad.)
- danpalmer 4y ago
  I can't remember exactly, it's been a year since I last did this. I believe there's a setting for the threshold at which this should be logged, so you could set it to log any expression that takes more than 100ms to type-check. By default I think it just times out at 10 seconds or something.
  - thewebcount 4y ago
    I looked into it, and found that you can add these "OTHER_SWIFT_FLAGS" to your project: OTHER_SWIFT_FLAGS = -Xfrontend -debug-time-expression-type-checking -Xfrontend -debug-time-function-bodies There's also this great WWDC session on build parallelization: https://developer.apple.com/wwdc22/110364 https://developer.apple.com/wwdc22/110364
gary17the 4y ago
> [Swift] values expressiveness, and having multiple ways to do things that means you can choose a nice way to express each line, rather than always being forced to write it the same way. There are at least two major problems with this kind of PL design approach: 1.) when you work on a large codebase from multiple contributors, all the possible combinations of the available syntax and standard library calls will eventually get used, making your brain frustrate quickly when reading code written by others, and 2.) when you interview for a new job, all the possible combinations of the available syntax and standard library calls will eventually be asked about by interviewers, making you look and feel like an incompetent programmer. I have to agree with the OP - Swift seems to be an unreasonably bloated PL. Unless one plans to work only with Swift all the time, learning all there is to learn about Swift on the way, it might be easier to just use Rust or Go.
- dagmx 4y ago
  Rust and Swift have about the same amount of syntax imho, and often share a lot of it. Go is simpler as a language but you end up writing more code to accommodate that.
  - gary17the 4y ago
    > Rust and Swift have about the same amount of syntax I wouldn't agree, I feel Swift has significantly more surface area than Rust. But even syntax and standard libraries aside, I think that Rust is significantly more "explicit", "consistent" and "predictable" than Swift. I consider those to be very important qualities in a PL. Maybe that's why Rust was easier to learn and memorize than Swift (with the exception of the Rust borrow checker and lifetime annotations that indeed have to be well understood to be even usable). But it might be just me.
    - dagmx 4y ago
      Hmm can’t say I agree about the significantly more surface area. I switch between rust/C++/Swift fairly regularly for work, and I think they’re roughly similar in complexity with the exception of Rust having lifetime annotations and Swift having computer properties. Where I do think Swift has a lot of noise though is @attributes. There’s just so many attributes to learn, especially if you happen to do SwiftUI or ObjC interop. Though rust has the same issue , it’s just there’s no ubiquitous UI lib like SwiftUI. I imagine it would have the same if it did.

dagmx 4y ago

The things you find ugly are the things that I think make Swift code quite pleasant to work with. More languages need a guard. It’s a really great control flow operator to flatten your code. Rust added `let else` last year that does the same and it does wonders to clean up code. There are things I dislike about Swift , like lack of explicit namespace organization (rust mod or c++ namespace keywords, and the enum trick does not count) as well as the ability to drop extensions anywhere (which leads to a lot of stream of consciousness programming). However I don’t think I’d really consider it ugly. What languages are you coming from and what else do you not like about Swift?

msie 4y ago
Coming from the usual languages: pascal, modula-2, objective c, c, lisp, miranda, ruby, python. Another thing I don’t like about Swift are the named parameters which was an objective C thing. I find it makes reading code difficult because you don’t start parsing a function call until the first ‘(‘, you have to read the args too to determine which function is being called. I also don’t like the integration of swiftui syntax into swift. Plus you read some of the stuff going on in swift evolution and it seems they are hell bent on adding everything to the language.
- dagmx 4y ago
  Personally (and totally subjectively) I’d argue that a lot of those languages you listed are ugly, with the exception of the last two. Some of them are nice looking for short bits but get really ugly for larger pieces of code. Especially when you practice defensive programming and are nested several levels deep because of the lack of optionals. The SwiftUI integration doesn’t materially change the language much. It’s based on passing in blocks as parameters and has been a norm for obj-c as well (effectively how everyone does completion handlers). But I think that’s why language beauty is in the eye of the beholder. To me, Swift allows flatter/cleaner code while defensively programming with lower branching and higher ergonomics. That’s beauty. That’s why guard is so nice. But I can see how it might be off putting if you’re coming from other PL paradigms. I think a lot of it comes down to whether people want simple syntax vs simple code. C for example is simple syntax but rarely ever simple code , Swift and rust are more complex syntax but much simpler code.

myko 4y ago

Surprised to see this opinion on `guard`! IMO it's such a nice feature for future developers looking at that code, it's a clear indicator to pay attention to this area of code and know exiting the function is important.

msie 4y ago
I may be too harsh on guard but I like small languages. When I first encountered guard I wondered if it was truly necessary to the language and it wasn't.
- dagmx 4y ago
  Many languages have ergonomic features that aren’t truly necessary but are worth having. I recognize you prefer smaller languages but I’d like to make a case for guards usefulness. Guard is great because it’s a combined early return and assignment. Imho if you have a language with optionals, it’s a required pattern to have, or you end up with lots of conditional unwraps and nested blocks, or lots of placeholder variables that you might accidentally use in your code later causing safety or memory access issues . Take the following code if let foo = Some(optional) {yourLogicHere} else {return} That’s one level of nesting. Swift is nice enough to elide the Some matching so you’d just have if let foo = optional {yourLogicHere} else {return} Still one level of nesting but a little cleaner. Now if you have a language based around safety, like Rust or Swift, a lot of functions return optionals. So you’ll keep nesting code in your checks for safety Now take a guard. guard let foo = optional else { return } yourLogicHere That’s one level of unnesting removed , and that compounds. Better yet, you can chain them guard let foo = optional, let spam = foo.lookup() else {return} The equivalent in C like languages would be type foo; if (!getOptional(&foo) return; Now either you early return in the case of the optional failing or you nest. Nesting gets repetitive and deep. Or you unnest like I have and have that foo sticking around un-initialized, potentially causing issues of use later. Guard simultaneously removes both conundrums and makes your code both neater and safer.
  - O-stevns 4y ago
    Adding to this excellent explanation, the guard is compile time checked too, so you can't accidentally screw up the early return like one could in say c or c++ It might seem like a quality of life feature to some, to me however it's an essential feature of swift and one of the better ones.