macOS Explain Swift to us Like We're 5 Years Old

[AdonisSMU]

No, I already said that it has some nice features there's no denying that. For now, the most important ones for me are the ones you mentioned and also the ability to assign values to sub-properties directly, lack of which in Obj-C has been annoying me for a long time. My main problem with Swift is its Syntax. I found it neither intuitive to use nor easy to read. I feel like it will be counter-productive for me to switch. Maybe I'll change my mind in the future.



That's true for newcomers. But if you already know the platform, the only thing left for you to learn is the language, which we already did once.

With the introduction of Swift, the newcomers to the platform now have to learn 2 languages in addition to the platform itself. This will change in the following years of course but the transition will be painful.

The new language is all syntactical stuff. Once you know Obj-C and the environment, I would think it would be easier to transition over to SWIFT. For newcomers they'll just learn SWIFT and pick up some Obj-C as they need to...

Logic is logic.

 

[firewood]

Sincere question: to a real-world user, what does "faster programs" mean?

Longer battery life.

Most UI/UX code is a race to sleep. The faster any task runs to completion, the faster the CPU gets to go to sleep in a much lower power mode, saving the users battery life.

Or for games that burn max battery anyway, smoother animation with more physical realism, more enemies, smarter game AI, etc.

 

[MeFromHere]

The only thing it does is changing the location where you have to think about the values a variable can have. In obj-c, you do it right after assigning something to the variable, while in Swift you do it when declaring the variable. If you forget to assign the value of the implicitly unwrapped optional returned from a method in the SDK to a variable defined with ?, the compile time checks are not gonna catch anything.

...

Swift does more than "change the location". The syntax is designed to make risky code constructs (which we do need sometimes, especially with the current Obj-C APIs) OBVIOUS in the code.

If you use a non-optional, the compiler makes sure the variable is initialized with a non-nil value before it's used.

The ugly "?" and "!" symbols with optionals serve as a warning to the reader. The compiler can't check that the usage is correct, so the people need to be extra careful. You're SUPPOSED to be more wary when you read (or write) code with optionals. And you're SUPPOSED to avoid optionals whenever you can.

 

[CutterSlade]

The ugly "?" and "!" symbols with optionals serve as a warning to the reader. The compiler can't check that the usage is correct, so the people need to be extra careful. You're SUPPOSED to be more wary when you read (or write) code with optionals. And you're SUPPOSED to avoid optionals whenever you can.

Yet you still have to remember making something optional when declaring it, and in the case of implicitly unwrapped optionals, you'll no longer have any "ugly" symbols around, which according to you are there to make you remind something. Swift's optionals are all about compiler checks that are done based on the developers annotations. You aren't safe if you don't annotate using ?s. It's not trying to warn you with those symbols, it's forcing you check for nil values depending on what you told it to check.

If we are talking what we're SUPPOSED to do, then you are SUPPOSED to pay attention not to make the mistakes Swift tries to prevent while using Obj-C in the first place.