Live data from Hacker News

Swift Regrets

belkadan.com

121–130 of 207 posts

Re: Swift Regrets

#121

I don’t know if this is Swift’s fault, per se but I find Xcode to be a real pain to use. There’s something about the Apple Way for UI/UX that just doesn’t jive well with an IDE experience. I find myself constantly jockeying around the various windows and panes within Xcode that I usually never have to bother with inside of Visual Studio.

Not an apple user, but I've heard that xcode is an ide+build system. Which means that you can't compile an application if you don't have the exact version of xcode installed. How true is that?

I'm not sure what you mean by "the exact version of xcode installed" but you can compile most applications with any recent version. Of course when new SDKs are released you need to update the Xcode version but it's not a big deal (and maybe a once a year thing).

It is an IDE + build system but you can totally write code in a different editor and compile it on the command line with xcodebuild.

Re: Swift Regrets

#122
A lot of these things are odd cases that I would never encounter, but I'm surprised that there aren't bigger, more idea stuff in here. For example, not having an expression oriented syntax is really hard for me (I.e. everything returns a value, even if that value is void or whatever).

Swift claims to have a lot of functional features, but it actually misses some of the most basic things.

Re: Swift Regrets

#123

So is Objective-C kinda going away after all? If I did a greenfield iOS or OSX app would it be malpractice to do it in Objective-C? Because I actually adore that language. Haven’t used it lately, but I do love it.

I thought Objective C was dead - it'll still be supported (probably) but https://developer.apple.com/ calls out Swift a lot but makes no mention of Objective C.

Re: Swift Regrets

#124
post #119

Earlier quoted context omitted.

> 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 se…

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.

Re: Swift Regrets

#125
post #118
post #50

Earlier quoted context omitted.

Apple professionals use Xcode. Using different tools than the ones Apple uses leads to a lot of problems that Apple are not interested in fixing. The days when a company like Metrowerks or Symantec could be a viable third party IDE supplier are long gone.

I don't do Apple development as much anymore, but I used to write in AppCode a lot and used Xcode only to build.

Alongside Xcode I find BBEdit very useful for editing data files, diagnosing merge problems, writing shell scripts, etc. I still do almost all my real coding in Xcode to use the autocomplete. Tower is useful for anything non-trivial in Git. For basic operations the Xcode Git support is useful.

Re: Swift Regrets

#126
post #50
post #21

Earlier quoted context omitted.

If you develop for iOS|macOS professionally, you may be interested in Jetbrains' AppCode [0]. Note: I'm not connected in any way to Jetbrains, and I have not used AppCode myself, but I used other tools from them, and they're quite competent, I'd say. [0]: https://www.jetbrains.com/objc/

Apple professionals use Xcode. Using different tools than the ones Apple uses leads to a lot of problems that Apple are not interested in fixing. The days when a company like Metrowerks or Symantec could be a viable third party IDE supplier are long gone.

I believe AppCode uses XCode behind the scenes for most of the magic stuff anyway. It's just a more capable facade.

Re: Swift Regrets

#127
post #76
post #56

Earlier quoted context omitted.

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

Re: Swift Regrets

#128

So is Objective-C kinda going away after all? If I did a greenfield iOS or OSX app would it be malpractice to do it in Objective-C? Because I actually adore that language. Haven’t used it lately, but I do love it.

Yes, you should learn Swift. The naming of things in Apple's APIs still comes through strong in Swift (due to named parameters), so it feels at home to programmers who were familiar with ObjC.

Swift protects you from many crashes/bugs with its null safety and more strict compiler. In ObjC many clear coding mistakes are only marked with warnings, which is not helpful.

Apple has clearly moved to Swift for all future development of new libraries, etc. So it would be foolish to stay in the past.

Re: Swift Regrets

#129
post #24

I'm surprised he doesn't bring up minor features that lead to huge compile time issues, like operator overloading and imports being module sized vs file or folder wide and type inference in some cases. Not to mention how the language doesn't actually scale that well with core count vs. many, many other programming languages. Throwing 64 cores / 128 threads at a C++ code base speeds up builds in a linear fashion durin…

This is a whole series of articles, and he does address type overloading in one of them, which is maybe what you're looking for.

https://belkadan.com/blog/2021/08/Swift-Regret-Type-based-Ov...

Re: Swift Regrets

#130
post #76

Earlier quoted context omitted.

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

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