Conversation

Notices

1. Embed this notice
   Ben Cohen (airspeedswift@mastodon.social)'s status on Sunday, 12-Jan-2025 04:57:35 JST Ben Cohen

   • Thomas Ricouard

   Over on Blue Sky, @dimillian posted a screenshot of code that stopped me in my tracks. It was just normal Objective-C code that he was considering rewriting in Swift. As he says, "it's not complicated, it's just verbose”.

   https://bsky.app/profile/dimillian.app/post/3lfeuxp2nk22w

   • Embed this notice
     Paul Cantrell (inthehands@hachyderm.io)'s status on Sunday, 12-Jan-2025 04:57:32 JST Paul Cantrell

     in reply to

     • Anders Hovmöller

     @boxed
     Yeah, `mFoo` just annoys the living shit out of me.

     I already hashed this ad nauseam out back on the aforementioned mailing list thread and am uninterested in further discussion now, so we’ll just have to agree to disagree on it here.

   • Embed this notice
     Ben Cohen (airspeedswift@mastodon.social)'s status on Sunday, 12-Jan-2025 04:57:33 JST Ben Cohen

     in reply to

     Another evolution that I love is the `if let x {` shorthand, instead of the (common) boilerplate `if let x = x {`. It simplifies and clarifies this common idiom.

     Once you know about it – each one of these is a thing for a newcomer to learn. But you learn a language once, then use it for years. Over-optimizing for beginners is the wrong trade-off. These simplifications aren't complex to explain and remember. And Swift's clean look attracts users from both high- and low-ceremony languages.

   • Embed this notice
     Ben Cohen (airspeedswift@mastodon.social)'s status on Sunday, 12-Jan-2025 04:57:33 JST Ben Cohen

     in reply to

     • Paul Cantrell

     Evolution can go the other way too. The `any` keyword for existentials for example (hopefully as a step towards swapping `any` and `some` to give us `var body: View`).

     But attempts to add back in ceremony in pursuit of clarity are usually heading in the wrong direction. Take the proposal to require explicit self on member access. The rejection quotes @inthehands: "anything that is widely repeated becomes invisible”

     I would go further though. Anything repeated gets in the way, reduces clarity.

   • Embed this notice
     Anders Hovmöller (boxed@mastodon.social)'s status on Sunday, 12-Jan-2025 04:57:33 JST Anders Hovmöller

     in reply to

     • Paul Cantrell

     @airspeedswift @inthehands This specific one I disagree with. I thought it was annoying when I switched frol C++ to python. But then I looked at C++ code that didn't do mFoo for members and screamed in horror. And idiomatic Swift does that all the time. Very iffy imo.

   • Embed this notice
     Ben Cohen (airspeedswift@mastodon.social)'s status on Sunday, 12-Jan-2025 04:57:34 JST Ben Cohen

     in reply to

     Swift has a lot of techniques for reducing ceremony and increasing readability that you can see in action if you think about what the equivalent code would be. That includes things like string interpolation, and a built-in concept of mutability and value types so you don't need NSMutable variants. And of course it does away with pointers in most cases. It has optionals so there's one way to spell “not found”, with sugar for handling them.

   • Embed this notice
     Ben Cohen (airspeedswift@mastodon.social)'s status on Sunday, 12-Jan-2025 04:57:34 JST Ben Cohen

     in reply to

     But the most dominant technique on display is the most controversial one: implicit defaults, that let you drop more syntax.

     You see if from the very first character, because Swift's default visibility is internal, so you don't need to mark internal methods with a sigil or keyword.

     And in almost every case, there is a very reasonable objection to that implicit rule. In this case, that internal methods might allow unintentional exposing of private invariants to other parts of your code.

   • Embed this notice
     Ben Cohen (airspeedswift@mastodon.social)'s status on Sunday, 12-Jan-2025 04:57:34 JST Ben Cohen

     in reply to

     Every line, almost every other keyword, has examples. Even the dropped trivia, like unnecessary semicolons and parens, has complexity and downsides, that the grammar and parser do an excellent job of hiding from you.

     The most celebrated appear on the second line: type inference means you wouldn't need to explicitly type `NSInteger cellIndex =`, just `let cellIndex =`. But still, type inference has its detractors. Much better to be explicit. Much safer. Much more readable.

   • Embed this notice
     Ben Cohen (airspeedswift@mastodon.social)'s status on Sunday, 12-Jan-2025 04:57:34 JST Ben Cohen

     in reply to

     But Swift still has plenty of ceremony. And it continues to evolve. Generics for example started off much more verbose. Swift 1.0 didn't even have protocol extensions. There's more that could be improved though. It would be lovely to just write `var body: View` and have it do the right thing (i.e. not return an existential). And again, there would be concern that's too "implicit”. That that `some` is load bearing. That the right landing place is you always have to state `any` or `some`.

   • Embed this notice
     Ben Cohen (airspeedswift@mastodon.social)'s status on Sunday, 12-Jan-2025 04:57:35 JST Ben Cohen

     in reply to

     Now I'm fully aware that there are plenty of people who still believe this code is better than Swift. But at this point I think they're a tiny minority.

     This screenshot demonstrates to me the fundamental core of why Swift strives to be a low-ceremony language. Not because all the ceremony shown here is a hassle remember or type, though it is.

     It's that the ceremony drowns out the core of what the code is trying to express: the business logic that is the actually important part.