Hacker News Reader

Comment by Koshkin | Hacker News Reader

For people coming from C/C++/ObjC, certain things in Swift can take some time to get used to, e.g.

  if case .Success(let person) = personResult { ... }

My first thought when I saw this was, "only a mother could love this syntax", but later you come to appreciate and enjoy it.

Link: https://www.natashatherobot.com/swift-guard-better-than-if/

View on HN

This is my personal gripe with Swift. Theres just so many different ways to form expressions and do control flow. It just feels like code golf to me.

  for case let (title?, kind) in mediaList.map({ ($0.title, $0.kind) }) where title.hasPrefix("Harry Potter") {
     print(" - [\(kind)] \(title)")
  }

http://alisoftware.github.io/swift/pattern-matching/2016/05/...

I don't know Swift much, but can tell at first glance that you're mapping items from `mediaList` into (title, kind) tuples, filtering for missing titles and "Harry Potter". I guess it's more about being comfortable with functional programming patterns in general, than its syntax.

That’s the biggest reason I don’t like Swift- it’s terrible syntax.

I hate let, var, func. I hate the backwards variable definitions. I hate the crazy punctionation symbols (dots, question marks).

I agree with a lot of what Smith says about Objective-C. But my biggest personal reason is the above. I find Objective-C beautiful and Swift ugly.

> Objective-C beautiful and Swift ugly

That's subjective. Unusual - yes, but ugly? Why? I'd say, it is quite beautiful, in its incomprehensibility (to the untrained eye).

I find this fascinating because the main reason I never did iOS development at all (as a hobby) is that I found Obj-C just so goddamn ugly and awful (java level ugly) that I avoided it.

Swift changed that completely. I finally find native iOS readable.

If you use it for more than a few hours you just wont think of it anymore.

I write in both ObjC and Swift. It takes more than a few hours to get used to both languages but it’s also true that you get used to both. I prefer the relative terseness of Swift and also find the language more elegant and safer than ObjC.

Tried that. Obj-C was just constant nails-on-a-chalkboard annoying. Too verbose, overly clunky syntax, etc.

So I’m afraid that wasn’t the case.

I guess hours was an understatement. The point is that I guess most people hate the style on first sight, I definitely hated it. But it's been a while and now I like it a lot, the verboseness makes the code and intentions clear (you just have to read a bit).

If it was the only open on iOS then yes, I could live with it.

It’s not - thank god - so I don’t have to. So I won’t.

Objective-C has verbosity that's very expressive and serves a purpose.

While true, I find I can do just as much in other languages that done have such an ugly verbose syntax.

It’s ugly for a reason but that still means it’s ugly.

Eh, I'd argue that its verbosity is less ugly than say Java.

I can see why people might thing square brackets are ugly, though I prefer it to the double-colon and angle bracket fest that is C++, but what else do you find uniquely ugly about Objective-C? Infix operators are nifty and promote clarity.

its

try it for a bit. you'll never look back, pinky wear.

Definitely subjective. It's easy to argue that it's actually the C family of languages that have a backwards declaration syntax - in case of complex declarations, not just backwards but completely crazy inside-out zigzag [1]. Yes, there's a logic in it, but it's definitely not intuitive. On the other hand, the "type-on-the-right" syntax is quite popular outside the C family. Pascal, Ada, Go, Scala, Rust...
[1] http://www.unixwiz.net/techtips/reading-cdecl.html

Not sure why this is (was?) being downvoted.
Yes it expresses a subjective opinion.
Programmer preferences on languages, tooling and other things involve subjective opinion. We are all humans, not purely rational automatons.
There is nothing wrong with a purely subjective, and taste driven argument. How much weight you choose to give it is another matter.

Very subjective, I for one like practically everything you listed as not liking about the syntax:
> I hate let, var, func
For me it increases readability, for example when I see let, I can make assumptions about it not being mutated, which is a huge win in a large codebase.
> I hate the backwards variable definitions.
To me it says, "this is a variable called x of type String", which seems to make sense to me, definitely more so that the C way.
I hate the crazy punctionation symbols (dots, question marks).
Question marks denoting optionals seems very clear, like "is String? really there?"
> I find Objective-C beautiful and Swift ugly.
See, I am the other way, I don't really find [[]] all that beautiful.

>when I see let, I can make assumptions about it not being mutated, which is a huge win in a large codebase.
What we know is that this won't work:
let p = Person("one") p = Person("two")
But we don't know whether this will work:
p.name = "three"
It depends on whether Person is a struct or a class, but that information is not available locally. let/var is fine, but in terms of information content it is strictly worse than what const can do in C.

You're right, if reference types are involved, it becomes tricky, however to the extent that Swift encourages value types, it still provides value.
> in terms of information content it is strictly worse than what const can do in C.
True, however the Swift community largely adopted a "use let first, only use var if absolutely necessary" approach, which is strictly better in terms of mutability-related bugs than what it was in ObjC/C, as mutability there is used much more liberally than in Swift.

Please - tell me that's not something one might actually encounter in practice (and yes I know, it'll feel clever to respond with up votes and down votes but please don't as I'll not have any idea what they mean: good point! Or stupid comment! Or you would totally see this! Or you wouldn't! And for the last two which vote is which?)

You would totally see this in the code I've been writing. I've been taking advantage of enums with associated values for things like state machines. Usually, you'll see associated values like this in a switch statement, but if you need to handle a specific case, then you'll see the `if case`.

You'll be surprised how soon after you start writing Swift you'll be doing this yourself - and enjoy it. Exploring new features and learning new ways of doing things is fun. Otherwise, what's the point in learning a new language? Seeing more of the same?

Not only is this not unusual it is completely normal and even banal when using Swift enumerations with associated values. It might look strange to someone who doesn't know the language, but a few minutes reading about Swift's enumerations will clarify what this code is doing and it will become totally mundane.
struct Person { var name: String } enum Result<T> { case success(T) case error(NSError) } func printName(personResult: Result<Person>) { if case .success(let person) = personResult { print(person.name) } }
In the example above, Result is an enumeration that can be either success or error. If it's success it has an associated value that is the result of whatever operation was successful. If it's error the associated value contains the error information.
In the case of printName() the success case contains a Person value. The if-case is simply saying that if the enumeration represents the success case then extract the associated Person value from the enumeration. The "let person" means make person a constant because you're not intending to modify it. If you wanted to modify it you'd use "var person" instead.
Hopefully this is pretty clear even to people not familiar with Swift style enumerations.

Ah, it's an ugly, verbose syntax for pattern matching. Got it :-)

Well, it's very similar to Scala's pattern matching. Not as elegant as Erlang or Haskell's. Objective-C, which is what Swift is being compared to here, doesn't have pattern matching. An attempt to write something similar in Objective-C would be much more verbose, unsafe and almost certainly uglier.

You may find it ugly, that's subjective - I personally find it weird and unintuitive. But you can't really say it's verbose, there is no redundant information there.

This is really the one construction in Swift that I find hard to understand and hence remember, it's not a very fair example.

Reply on news.ycombinator.com