Hacker News Reader

Comment by msoad | Hacker News Reader

Swift has way too many shorthand syntaxes. It feels nice from a language design perspective but when teaching Swift, you can see how confusing it is for the students. In larger codebases a lot of shorthands are forbidden by the organizations for consistency. So I'm not sure who's the real beneficiary for all those shorthands?

View on HN

The shorthands mystify me as well. I have taught a few courses using Swift and the shorthand notation, as well as implicit variables like oldValue and newValue in setters, are confusing. You can try to ignore them, but eventually a student will find them.

In my experience, teaching courses using Racket have had better outcomes. At the end of the Racket courses, I can quickly transition students to other languages, including Swift. It hasn't worked out so well with Swift. I am still gathering data so I can come to a better conclusion as to why.

> Swift has way too man shorthand syntaxes. It feels nice from a language design perspective but when teaching Swift, you can see how confusing it is for the students.

100% agree. As a late adopter of Swift, I spent a lot of time looking at code that was so stingy with information that it was challenging to even formulate a Google-able question from it.

Very much this. The original discussions around Swift talked about the value of being explicit rather than implicit and reducing surface area (for instance, no ++/-- increment/decrement operators). That goal appears to have been completely lost recently.

My impression following swift forums is that original core team members were very concerned about relying a lot on first principles, whereas the new generation is more about building powerful constructs, in a fast paced way.

The new generation doesn't seem to have a need for extracting substrings from strings then. The existing Swift syntax for slicing strings [1] is horrible.

[1] https://www.cocoaphile.com/posts/string-slicing-in-swift

You can find a few extensions on stackoverflow that makes subscripting work with integers on strings. I'm still unsure why this isn't part of the stdlib..

This is a product of UTF-8 encoding, isn’t it? What’s the third index of “Füß”?

There is no reason they can't come up with a more readable API that works. Python says it's 'ß' and I'm fine with it as long as it's consistent:

  >>> "Füß"[2]
  'ß'

That article is terrible. Simple wrapping a string in Array() converting it to characters achieves what the author desired and makes the rest of the article pointless.

The article is only for demonstrating how standard library works (it was the first Google result for me). The point is we shouldn't need to convert a string to an array of characters to manipulate it.

> The point is we shouldn't need to convert a string to an array

Yes we should. Unicode strings have ambiguous lengths. I would encourage you to try slicing Unicode strings sometime to understand why this is true.

Consider the black Santa emoji. What is the length of that emoji? Backspacing an emoji deletes it, so it could be one. But then how would you substring slice out the skin color component of the emoji?

Converting a string to an array yields the symbols on the screen separated by the cursor position, but that’s not a true representation of the data.

This is a typical example of overengineering.

When one speaks about "string slicing" they don't mean stripping the skin colour of an emoji. If there is a black Santa emoji in a string, I want to keep that Santa black. I am not interested whether it's a composite emoji or not.

The simple syntax should cover 99% of use cases and there should be a special, more advanced syntax for the rest, one that you'd use if you are writing an Emoji parser.

No, it's not overengineering. It's working with unicode. You have to let go of the idea that a string is a sequence of characters separated by where your cursor pauses. It's not. Black Santa was a simple metaphor for more real-world scenarios such the chinese language, in which multiple characters form to create a new character.

Imagine if you had a Color key on your keyboard, and a Santa key on your keyboard. Each key individually has meaning. When the two characters are positioned adjacent to each other, you get SkinColorSanta as one single character.

What is the new length of your string? Two for each original Color and Santa characters? Or 1 because there is only one icon the represents the two together? Remember Swift interops with C, so what is the size when you need to drop to char*? Hope you don't plan to use 1!

How would you solve this problem? Swift is open source. Make a PR if you have a better solution.

I'm not sure if we are on the same page. I am simply talking about syntactic sugar, not semantics.

To restate, I still don't understand why you think

    str.dropFirst(1).dropLast(2)

handles unicode better than

    str[1:-2]

What does dropFirst(1) drop if the first _element_ is a Black Santa? Why can't whatever it does be implemented using the bracket syntax?

> So I'm not sure who's the real beneficiary for all those shorthands?

Coffee shop and college project app developers who are chasing the cool (be it tricks or frameworks).

That’s not a knock, but that’s who I see using these things.

We were hiring a guy for a Flutter app that had no previous experience in Dart, but turned us down because Dart lacked some whiz bang feature he had too grown accustomed to. I did not see this as a loss.

Could I ask what feature they were looking for? I haven't used Flutter in a while, but it left a good impression. I remember being far less annoyed using Flutter than I am using other declarative frameworks like SwiftUI.

I’m an embedded C guy, so you’ll have to forgive my ignorance on this. All this high level stuff is magic to me.

But I want to say it was something larger than a conditional style or pattern matching and probably a state management framework. IDK, I had a good laugh about it and moved on.

EDIT: As to good impression, yes, we’re very happy with Flutter.

i think there's a growing concern about the language complexity. I hope next releases are going to be about trimming down the language, and consolidating the not-so-sexy but very important other aspects (multiplatform, compilation speed, spm, tooling, etc) following golang's example.

Reply on news.ycombinator.com