It is a fact of human psychology I think that the more languages one learns, the more the start to blur together, because they are all fairly similar in some ways feature-wise and many share syntaxes. Only a few languages stand out as unique and memorable, for instance Objective-C but even that is an echo of Smalltalk in terms of syntax.
However it is also a fact I find that because they blur together, the peculiarities of any one language become more easy to forget if I am switching between languages. The case in point here is Swift, which is becoming more peculiar as time goes on. The syntax, the special cases as regards optionals and memory management, they conspire to make it an oddity.
It resembles Kotlin, it can support the same program operations that ObjC can support, and it may seem friendly to Python fans, but it is not memorable I'm finding. Every time I return to Swift, I have to relearn its peculiarities.
Xcode makes that relearning kind of awful, because it is constantly interrupting me. I found that when I was learning Swift on Linux, it was much easier perhaps because there is no Xcode.
What can be done to mitigate the drift of Swift into arcaneness? What can be done to prevent it from becoming like a compilation of the Freemasons' secret handshakes and secret symbols?
Are you referring to the error/warning messages? I usually find those very helpful. If you don't like Xcode, then don't use it. You can use VSCode on macOS as well.
No, the problem is constant pop-ups interrupting my typing. It doesn't happen with such severity when I'm coding in ObjC, although my muscle memory is tuned better to that language. But for instance writing C++ in Qt creator, or Java in Android Studio is a breeze by comparison to Swift in Xcode, which is a nightmare especially if I need to write code quickly. Whereas writing Swift in vi is no problem because I'm not interrupted.
Hard to say really. I would suggest not coding in Swift for 6 months and then come back to it. To make a quick assessment, which is not complete and shouldn't be taken as such: The optionals problem and arcane syntax just don't exist in most other languages. For instance in ObjC its equivalent is the practice of comparing pointers to nil, which everyone does as a matter of course and doesn't require a new language feature. The Swift syntax is also unhelpfully different e.g. to some of the same features in Kotlin. In a sense what makes relearning Swift awful is that it micromanages the programmer, like your worst supervisor at work ever, and doesn't trust the programmer to do the right thing. That seems wise until one notices it's also condescending. It's a language that nitpicks, but does it in a way that requires relearning its secret handshakes. In Xcode, that nitpicking is in the form of constant interruptions.
It’s a language that allows you to get extremely low-level if you need to. It doesn’t stop you from doing dangerous things, it stops you from doing them casually.
There isn’t much arbitrary behavior in Swift, to my eye. I find it easy to pick up after a long time using other languages, so long as you pay attention to documentation rather than trying to rely purely on memory.
Is this somehow different in Swift? It just makes implicit requirements explicit, and saves you the trouble. The only language feature Swift has for Optionals is the postfix ? operator. The rest is actually pattern-matching, which you can use for plenty of other things.
If you really hate all the checks, you can bypass them: use Optional.unsafelyUnwrapped and you can experience the joy of not having any idea what is nil and what isn’t. I wouldn’t recommend it, since you could get the same result by using the postfix ! operator and -Ounchecked, but it’s there.
While I want to help (and I'm sure many of us here do), I could only glean very little specific information from the discussion so far. So that's quite tricky whether to give a recommendation, propose a new guideline, etc.
Yeah, I agree that optional-related syntaxes had been unique to Swift*. However, its existence/introduction is what I will forever appreciate. That said, there are indeed a good number of rough edges and could be improved upon, e.g., how optional chaining doesn't work w/ function calls easily, though I don't think any of those are your particular beef w/ the language.
There's a lot of non-info here, but do you mean Xcode's auto-complete?
Again, it's hard to figure out when there's little specificity here. AFAICT, do you refer to how you need to specifically identify unwrap operations for optional values (x?. vs x!.) when using them?
* Other languages also introduced something similar (wiki). I won't go and figure out which language does it first. That's not relevant to the discussion anyway.
A basic problem in programming is when a feature of a thing is not expressed clearly but that feature is then used, so the programmer or code reviewer has to deduce that the feature exists.
So in Swift, optionality is never expressed in the variable name e.g. no one calls a variable optionalResult they just say result. So while using result, one has to recall that it's optional while typing and choose appropriate syntax. But what Xcode does is, it intrudes with a popup to say that some error will result if you do it that way, like a micromanager standing behind you telling you what to type.
Compare that to ObjC, where you always know based on context whether an object pointer could be nil e.g. a button pointer is only nil before its object is created in the GUI set up logic.
Sure the concept is universal but the Swift implementation seems to cause confusion for people, because like the abandoned language APL it tries to condense complex concepts into single characters.
You know you can turn off autocomplete in Xcode, right? Preferences -> Text Editing -> Editing -> "Suggest completions while typing".
The issues you bring up are nothing new. There was much angst in the Obj-C community seven years ago when Swift was first announced and suddenly Apple wanted us to explicitly track nullable references. "Obj-C is nil safe," we said. "Why do we have to this? This is such a waste of time!" Turns out it wasn't so safe and optionals save us a lot of time and money and ship safer software at the same time.
My suggestion: get used to it. This is how Swift works, it isn't going to change, and your code is better off adopting the higher level representations.
That's a claim without evidence and yet it's the core of your argument. Is it possible that code that you wrote in ObjC wasn't safe, and if so then then shouldn't you have written better ObjC code?
But other languages also use condensed symbols (?., ?, @ ?, &.) . They are quirky in their own rights, but I don't immediately see any unifying syntax here.
Let's not bicker one another and have a level-headed discussion here.
It seems clear you're not here for a serious discussion. I suggest you research the initial reactions to Swift in the Obj-C community, null safety in general, and the syntax of other modern languages and how they deal with nullability. You'll see that Swift isn't unique, that this is a larger industry trend, and that software quality has benefitted as a result.
Yes, only Java seems to minimize the symbols, to its credit. It was an excess of symbols that made people reject APL. Limiting it to just a few may seem OK but in the end, this feature of implicitly allocating an extra object for optionality and using special symbols to deal with it is one part of Swift that requires relearning or rethinking when returning to Swift from other languages. But it is not really the symbols that are the problem, it is the optionality that is unusual. Saying that five other not very popular languages also use it isn't a good justification for it.
That's not actually true based on the Swift code I've seen in industry. There is a lot of force unwrapping out there that causes app crashes, because of the confusion that people have about optionality.
Swift's designers have tried to get too clever with the syntax and that has established what I call a set of secret handshakes that don't benefit anyone and don't improve software quality.
@ubu, this is a working forum for evolution of the Swift language. What ideas regarding changes to the language are you bringing forward, and what sorts of feedback on those ideas are you hoping to solicit from the community to help you to drive them to a proposal stage?
Eliminate any syntax that is "too clever by half". If you spend 6 months away from Swift and come back to it, much of its syntax is arcane and only shared with some unpopular languages. Eliminate anything that is arcane and unintuitive. People are writing bad Swift code because they don't understand the syntax and concepts. Make optionals optional i.e. they shouldn't be required. I think a lot of the promise of Swift has been wasted by people making it so arcane.
I'm not sure if trolling, but the wiki, has 20 languages (well, 18-ish), including the Kotlin. Most of which seems to be introduced in the past few years. So yea, it seems like a coming trend.
PS
This might fit better w/ a more general Using Swift thread.
. They are quirky in their own rights, but I don't immediately see any unifying syntax here.