Why Is Swift's Syntax So Complex?

If I want to see an alert using Swift I have write about 4 lines of confusing code/syntax in various parts of my code. And that, to me at least, is ridiculous.

Why can't it just be something like this...

alert("Hello World!")

That is obviously a LOT easier. And it takes a lot less time to learn!

So the code would be something like this....

If x = 1 then
alert("Hello World!")

In other words, you don't have to declare or set the state of the alert in terms of it being visible or not.

Because surely an alert should be invisible by default and then, when you type...

alert("Hello World!")`

The alert then becomes visible.

To me writing less code (that's still easy to read and understand) is a no brainer. It's like the "less clicks is better" system used in web design.

And this is just one example!

Today I had to, and struggled to, convert a variable into text (not a string for some reason) just so I could put it in an alert.

Here's some of the code....

.alert(isPresented: $showAlert) {
Alert(title: Text("\(mynumber)"))

That is..... I don't know..... Preposterous?

The objective or programming is to get something done. And the easier it is to do, the more productive we can be. So, again I ask....

Why is Swift's syntax so complex?

This has nothing to do with Swift's syntax per se; in this example you're just asking that a particular UI framework makes a particular task easier for your particular use case.

There are dozens of ways to counter-argue this; one important counterpoint to this flavour of simplicity is the absolute lack of customisability — in my work, I want to track the state of my alerts so that, for instance, my code doesn't present more than one at any given time. If a framework cuts away such hooks, I will not be able to get this done, thus undermining "the objective of programming", by the same logic.

1 Like

It's not "swift syntax", it's SwiftUI way of doing things, and the reason this particular thing is more complex in SwiftUI because whatever you see on screen at any given moment is a pure function of state, not a result of a sequence of steps as in UIKit.

FWIF, you can still cross the two worlds and do this in the otherwise SwiftUI app:

func showAlert(_ text: String) {
    let alert = UIAlertController(title: text, message: nil, preferredStyle: .alert)
    alert.addAction(UIAlertAction(title: "OK", style: .default))
    UIApplication.shared.keyWindow!.rootViewController!.present(alert, animated: true)
}
...
showAlert("Hello World!")
3 Likes

I wish I had a means to convey just how complex "simple" can get, but it's something I think you've need to experience and be burned by to fully grasp. UIKit and AppKit are remarkably simple (albeit large) frameworks that let you compose your entire app in terms of simple commands not too unlike alert("some message").

And then the questions start: "How do I know if the alert is currently open or not?", "How do I dismiss the alert programmatically?", "How do I bind the actions on the alert buttons to do something in my app", and then that's where the pain train starts.

The alert example from the Javascript/Web development space is particularly interesting choice of example, because that area has already gone a heavy transformation into declarative-style UI programming with frameworks like Vue.js and React. Outside of desperate print-style debugging, you won't really see any imperative calls to alert within any serious moderm web applications. The whole industry (including Apple now, with SwiftUI) is moving towards a reactive-programming model, where UI is automatically generated from a function of explicit program state.

7 Likes

The code you include is doing a lot more than just presenting an alert. For instance, it is providing a mechanism for you to programatically control when the alert appears and disappears, via the showAlert boolean. If you just want to put something up on screen and have a default "OK" to dismiss it, this might seem like slightly more code. But it provides you with a lot more flexibility. It's also to do with the difference between a declarative UI framework like SwiftUI vs. a procedural approach to code.

This is a good example of the boundary between the Swift language and a UI framework. A String in Swift is 'a series of characters that forms a collection', a data structure for holding unicode-compliant characters. In contrast, Text is a part of SwiftUI, and is a type of View for displaying string-based data to a user. (You created a string literal from your interpolated variable mynumber, and passed it to that Text view.)

There is certainly a significant learning curve in learning both the Swift language and new frameworks like SwiftUI at the same time. One great resource that works through a lot of this material in a really accessible way is Paul Hudson's free 100 Days of SwiftUI online course.

3 Likes

I'm sorry but I'm not as smart as you people.

So can someone please answer this question in 20 words or less in a simple way (ie: in a way that does not require a degree in computing science)?

Thanks.

Let's forget about programming for a minute. All language (human or computer) is about communicating an idea. Some languages have many words, and some have few. Some have short words, and some have long words. Some have many words that say the same thing with different nuance, and some have just one, or none at all.

This makes certain languages able to convey some ideas more effectively than others, and usually, the more "important" a concept is for a language to want to express, the shorter a word it is. But there's a tradeoff: there are only so many short words you can make, so less important concepts usually need to be relegated to longer words.

Usually, too, the simpler an idea is, the fewer words a language will need to talk about it.

A language that's really good about talking about certain ideas will have certain ideas that it can't talk about as easily. Cultural priorities, history, etc., shape how a language works over time to "optimize" for the concepts that the speakers find more important.


The relevance:

  • In a language like JavaScript, the "idea" of presenting an alert is "simpler" (there are few configurations possible for what an "alert" is/can do), so the single word alert may be enough to express the concept
  • In Swift on iOS, the "idea" is more complicated (there are many configurations possible for what an "alert" is/can do), so it requires more words to express clearly and without being ambiguous

Part of what others have tried to explain: the idea you're trying to express doesn't come up nearly as often as other ideas, so it takes more words to say than they do. If it was more common to need to express this idea, we'd come up with shorter words to say it, as you suggest.

You can come up with your own words for some ideas (i.e., writing a function to do what you want) and use those, too, if you need to say them very often.

(And in general: Swift tries to be a language that is good at saying many different things effectively, which means that there are many individual ideas that other languages can be better at saying, with the tradeoff that they may have a harder time expressing the majority of ideas that Swift tries to talk about.)

11 Likes