5 ms·

I think the author should do some more reading about Swift. He complains about a lack of inferred typing and pattern matching, two things which Swift does suppo

by e28eta 11y ago

I think the author should do some more reading about Swift. He complains about a lack of inferred typing and pattern matching, two things which Swift does support. It's more limited than Haskell, but it's there. I also disagree with his statement that Objective-C is better for writing an operating system. He seems to conflate using Xcode with the built-in support it has for xibs to do UI layout. You don't have to forego all of the features of the IDE just because you prefer to do UI layout in code.

e28eta 11y ago
Replying to myself, because I thought about this a little more. I'm someone who's very excited about Swift. But I'm also interested in learning a variety of languages (and seeing their influences on Swift feeds my excitement). It's easy to pick on specific mistakes in the article. However, what I think really bothered me is the criticisms of Swift that didn't show an understanding of why Swift is the way it is. And perhaps that's unfair to the author - who's just writing up his experiences. I like seeing well reasoned criticisms. I dislike value judgements that don't seem to acknowledge the trade offs involved in all software engineering.
omaranto 11y ago
Does he actually say anything wrong about Swift's type inference? I only found a spot where he mentions you need to declare types, which I thought was true at least in some spots.
rubiquity 11y ago
The author is one of the creators of Erlang which is a language that takes pattern matching above and beyond what Swift does (as well as Standard ML/OCaml/etc).
allsystemsgo 11y ago
> You don't have to forego all of the features of the IDE just because you prefer to do UI layout in code. I don't understand why you would do your UI layout in code if you can avoid it. If someone ever joins my team or inherits my code base, they're now partly responsible for maintaining the UI. Xib's and storyboards help with maintainability, legibility, and drastically lower the number of lines of code. The author even says: > Find an example program that works then reduce lines until I can reduce no more making a minimal example that works - then understand every line If you care about the line count, then why are you doing all your UI in code?
- seivan 11y ago
  Well until Xcode 6 (I think). Neither xibs nore storyboards were indexable. Meaning if you wanted to find something related to your layout, you would had to search through xml. Also much easier to refactor typed code than xml ;)
  - allsystemsgo 11y ago
    Wait, why would you fix your layout bugs by searching through XML? Why not just use interface builder?
    - seivan 11y ago
      Because you'd have to manually go through maybe > 39 scenes spread across 10 storyboards manually keep track of what's changed and find the next outlet you want to modify.
- cballard 11y ago
  Layout done in code: - Is type-safe, which is verified at compile-time. - Will break at compile-time if a breaking change is made. - Can be null-safe, without having to use Optional for everything. - Can do things iteratively. - Can use constants, so that you can easily modify standard paddings and sizes globally with one change. So those are some of the advantages of doing layout in code.
  - allsystemsgo 11y ago
    Right but you'd have to document what each constant represents. Interface builder gives us a universal language. You know what the UI will look like or how it will resize etc. because it's right there. There's no confusing constant names with magic numbers. You know the why behind the constraint values because you can see it.
    - deleted 11y ago
      [deleted]
masklinn 11y ago
> He complains about a lack of inferred typing and pattern matching, two things which Swift does support. 1. Swift only implements local type inference (which the user makes use of), languages like Haskell or MLs support global type inference. That is, Swift does not infer function types. 2. Swift's pattern-matching support is more limited than Haskell's or Erlang's[0] and function toplevels aren't pattern-matched whereas Haskell's or Erlang's are. [0] notably, you can't use refutable patterns in Swift, while they're very common in Erlang, and by default only a limited number of type classes — tuples, enums, ranges and atoms IIRC — can be matched, you can't destructure an arbitrary structs by pattern matching. On the other hand, Swift's pattern-matching can be extended (by overriding ~=)
- ridiculous_fish 11y ago
  Isn't switch an example of refutable pattern matching in Swift? You can distinguish enums, and use where clauses: switch read(/* stuff */) { case 0: print("EOF") case let amt where amt > 0: print("Read \(amt)") default: print("Errored") } The 'let amt where...' is a refutable pattern, isn't it?
  - masklinn 11y ago
    Ah yes I forgot to write the "in var/let" part which was supposed to be there. That is you can only use refutable patterns in `switch` (and `if let`/`while let` though I believe those are still restricted to Option, not general-purpose as in Rust, that correct?). In Erlang you can use a refutable match in an "assignment", that's basically a pattern assertion, a more general-purpose version of Swift's forced unwrapping.
rdtsc 11y ago
> two things which Swift does support For some value of "support". If you mean compared to C, yes it has pattern matching. If you mean compared to what Haskell, Erlang or Elixir has, not as much. The author is one of the creators of Erlang so from his point of view pattern matching is severely lacking. I have used Erlang, Python, C#, C++, Java and yes, I though Python had pattern matching compared to Java. But then used Erlang and realized that Python doesn't have pattern matching ;-) It is one of those things that once you use it, it is very easy to notice when it is lacking.
- masklinn 11y ago
  > yes, I though Python had pattern matching compared to Java. Python doesn't have pattern matching at all though, and doesn't advertise such a feature. It has iterables unpacking.
  - rdtsc 11y ago
    You are right. I was saying that coming from C, it seemed like pattern matching and a really cool feature. Until someone found how pattern matching works in Erlang or Haskell. Even in Python to its credit, iterable unpacking pretty nifty. It can now even do stuff like: https://www.python.org/dev/peps/pep-3132/ https://www.python.org/dev/peps/pep-3132/ >>> a, *b, c = range(5) >>> a 0 >>> c 4 >>> b [1, 2, 3]

by e28eta 11y ago

e28eta 11y ago

Replying to myself, because I thought about this a little more. I'm someone who's very excited about Swift. But I'm also interested in learning a variety of languages (and seeing their influences on Swift feeds my excitement). It's easy to pick on specific mistakes in the article. However, what I think really bothered me is the criticisms of Swift that didn't show an understanding of why Swift is the way it is. And perhaps that's unfair to the author - who's just writing up his experiences. I like seeing well reasoned criticisms. I dislike value judgements that don't seem to acknowledge the trade offs involved in all software engineering.

omaranto 11y ago

Does he actually say anything wrong about Swift's type inference? I only found a spot where he mentions you need to declare types, which I thought was true at least in some spots.

rubiquity 11y ago

The author is one of the creators of Erlang which is a language that takes pattern matching above and beyond what Swift does (as well as Standard ML/OCaml/etc).

allsystemsgo 11y ago

> You don't have to forego all of the features of the IDE just because you prefer to do UI layout in code. I don't understand why you would do your UI layout in code if you can avoid it. If someone ever joins my team or inherits my code base, they're now partly responsible for maintaining the UI. Xib's and storyboards help with maintainability, legibility, and drastically lower the number of lines of code. The author even says: > Find an example program that works then reduce lines until I can reduce no more making a minimal example that works - then understand every line If you care about the line count, then why are you doing all your UI in code?

seivan 11y ago
Well until Xcode 6 (I think). Neither xibs nore storyboards were indexable. Meaning if you wanted to find something related to your layout, you would had to search through xml. Also much easier to refactor typed code than xml ;)
- allsystemsgo 11y ago
  Wait, why would you fix your layout bugs by searching through XML? Why not just use interface builder?
  - seivan 11y ago
    Because you'd have to manually go through maybe > 39 scenes spread across 10 storyboards manually keep track of what's changed and find the next outlet you want to modify.
cballard 11y ago
Layout done in code: - Is type-safe, which is verified at compile-time. - Will break at compile-time if a breaking change is made. - Can be null-safe, without having to use Optional for everything. - Can do things iteratively. - Can use constants, so that you can easily modify standard paddings and sizes globally with one change. So those are some of the advantages of doing layout in code.
- allsystemsgo 11y ago
  Right but you'd have to document what each constant represents. Interface builder gives us a universal language. You know what the UI will look like or how it will resize etc. because it's right there. There's no confusing constant names with magic numbers. You know the why behind the constraint values because you can see it.
  - deleted 11y ago
    [deleted]

masklinn 11y ago

> He complains about a lack of inferred typing and pattern matching, two things which Swift does support. 1. Swift only implements local type inference (which the user makes use of), languages like Haskell or MLs support global type inference. That is, Swift does not infer function types. 2. Swift's pattern-matching support is more limited than Haskell's or Erlang's[0] and function toplevels aren't pattern-matched whereas Haskell's or Erlang's are. [0] notably, you can't use refutable patterns in Swift, while they're very common in Erlang, and by default only a limited number of type classes — tuples, enums, ranges and atoms IIRC — can be matched, you can't destructure an arbitrary structs by pattern matching. On the other hand, Swift's pattern-matching can be extended (by overriding ~=)

ridiculous_fish 11y ago
Isn't switch an example of refutable pattern matching in Swift? You can distinguish enums, and use where clauses: switch read(/* stuff */) { case 0: print("EOF") case let amt where amt > 0: print("Read \(amt)") default: print("Errored") } The 'let amt where...' is a refutable pattern, isn't it?
- masklinn 11y ago
  Ah yes I forgot to write the "in var/let" part which was supposed to be there. That is you can only use refutable patterns in `switch` (and `if let`/`while let` though I believe those are still restricted to Option, not general-purpose as in Rust, that correct?). In Erlang you can use a refutable match in an "assignment", that's basically a pattern assertion, a more general-purpose version of Swift's forced unwrapping.

rdtsc 11y ago

> two things which Swift does support For some value of "support". If you mean compared to C, yes it has pattern matching. If you mean compared to what Haskell, Erlang or Elixir has, not as much. The author is one of the creators of Erlang so from his point of view pattern matching is severely lacking. I have used Erlang, Python, C#, C++, Java and yes, I though Python had pattern matching compared to Java. But then used Erlang and realized that Python doesn't have pattern matching ;-) It is one of those things that once you use it, it is very easy to notice when it is lacking.

masklinn 11y ago
> yes, I though Python had pattern matching compared to Java. Python doesn't have pattern matching at all though, and doesn't advertise such a feature. It has iterables unpacking.
- rdtsc 11y ago
  You are right. I was saying that coming from C, it seemed like pattern matching and a really cool feature. Until someone found how pattern matching works in Erlang or Haskell. Even in Python to its credit, iterable unpacking pretty nifty. It can now even do stuff like: https://www.python.org/dev/peps/pep-3132/ https://www.python.org/dev/peps/pep-3132/ >>> a, *b, c = range(5) >>> a 0 >>> c 4 >>> b [1, 2, 3]