4 ms·

Genuine question - does this not highlight a problem with the language on some level?

shaggyfrog 7y ago
If a developer is just fiddling with optional-related operators until the compiler is happy -- in any language, not just Swift, e.g. Kotlin -- instead of actually understanding what they are doing at any fundamental level, that's not a language problem. I wouldn't want to work with someone like that I doubt anyone else would, either.
- geofft 7y ago
  I would believe it's an education problem, in that we teach things like recursion and local variables (the fact that the same variable can have different values in a nested call to a function) in intro CS classes but we don't really teach how post-NULL languages handle optionals (Option, Maybe, etc.). But it's something that should be part of an effective programmer's knowledge. It's not too unlike buffer overflows—all the people writing UNIX until 1988 were skilled, educated, experienced people, but at the time none of them were really aware just how bad buffer overflows were.
  - shaggyfrog 7y ago
    I never learned those in university, so I don’t think that’s a sufficient excuse. Any developer should understand, or want to understand, the fundamentals of the language they are using.
millstone 7y ago
It highlights some of challenges of bridging Swift with ObjC APIs.
- kitsunesoba 7y ago
  Fully Swifty UIKit or whatever it is that eventually replaces UIKit can’t come soon enough. As Swift has matured, UIKit/AppKit has quickly become the weakest link in the Apple platform dev experience.
  - millstone 7y ago
    Yes, which Apple has done with some success (Toolbox -> Carbon -> Cocoa) but we've also seen how WPF, etc have gone down. The hard challenge is the migration path, and you can't commit until the language and tooling is ready.
pixelrevision 7y ago
Optionals when used right really cleans up code that deals with a lot of deeply nested data structures. There is a learning curve though. When you are not used to them so there’s a lot of frustration and sometimes forced unwrapping until it clicks.

If a developer is just fiddling with optional-related operators until the compiler is happy -- in any language, not just Swift, e.g. Kotlin -- instead of actually understanding what they are doing at any fundamental level, that's not a language problem. I wouldn't want to work with someone like that I doubt anyone else would, either.

geofft 7y ago
I would believe it's an education problem, in that we teach things like recursion and local variables (the fact that the same variable can have different values in a nested call to a function) in intro CS classes but we don't really teach how post-NULL languages handle optionals (Option, Maybe, etc.). But it's something that should be part of an effective programmer's knowledge. It's not too unlike buffer overflows—all the people writing UNIX until 1988 were skilled, educated, experienced people, but at the time none of them were really aware just how bad buffer overflows were.
- shaggyfrog 7y ago
  I never learned those in university, so I don’t think that’s a sufficient excuse. Any developer should understand, or want to understand, the fundamentals of the language they are using.

millstone 7y ago

It highlights some of challenges of bridging Swift with ObjC APIs.

kitsunesoba 7y ago
Fully Swifty UIKit or whatever it is that eventually replaces UIKit can’t come soon enough. As Swift has matured, UIKit/AppKit has quickly become the weakest link in the Apple platform dev experience.
- millstone 7y ago
  Yes, which Apple has done with some success (Toolbox -> Carbon -> Cocoa) but we've also seen how WPF, etc have gone down. The hard challenge is the migration path, and you can't commit until the language and tooling is ready.

pixelrevision 7y ago

Optionals when used right really cleans up code that deals with a lot of deeply nested data structures. There is a learning curve though. When you are not used to them so there’s a lot of frustration and sometimes forced unwrapping until it clicks.