Earlier quoted context omitted.
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 de…
Metal is a mix of Objective-C and C++ (MSL C++14 dialect). So it will stay around for a while.
Swift Regrets
161–170 of 207 posts
Re: Swift Regrets
#162Earlier quoted context omitted.
Absolutely this. Having accidental null values floating around a program should not be a thing in the year 2021. And that’s exactly what some languages are fixing, like Swift. This problem is also one of the reasons why I got so frustrated using clojure.
The question mark syntax just moves this burden to some other layer of abstraction.
Re: Swift Regrets
#163Earlier quoted context omitted.
A well jelled team, with senior engineers can be much more productive with Objective C. But for beginners, swift looks less intimidating due to its syntax familiarity. The language pitfalls become apparent as you dive into it. Perhaps that’s why swift in ML and other areas failed. People don’t like the language. In iOS you are forced to use it. I hope the swift team does some hard thinking and start slashing features…
This just isn't true. Given equal familiarity, Swift will be vastly more productive at any skill level. Of course you can always tunnel deeper into more sophisticated solutions using Swift, since Obj-C lacks most of its capabilities, but that's hardly an equal comparison.
Just observe how much the iOS community talks about Swift patterns. Objective-C was more like Go, in that you accept your fate, keep things simple, and write some boilerplate code here and there. It seems to drive some people crazy, but it also avoids C++-style meta discussions about language features.
Whether this trade-off increases or decreases productivity depends on your team.
Re: Swift Regrets
#164Earlier quoted context omitted.
Metal is a mix of Objective-C and C++ (MSL C++14 dialect). So it will stay around for a while.
What in MSL is based on Objective-C?
MSL is a C++14 dialect, while everything else in Metal is Objective-C.
Metal demos done in Swift make use of language bindings.
Re: Swift Regrets
#165Earlier quoted context omitted.
I have jumped into several badly written ObjC projects and I skimmed the source code of every CocoaPod that I've used, and I have never seen ObjC code that used C string/memory handling "most of the time". Not even when ObjC required manual reference counting. Except for a couple of malloc'd C arrays (as an optimization over using NSArray ), most of it was for interop with C libraries, the same code where in Swift yo…
What can I say, lucky you. Now try the same with a couple of offshored projects from some famous consulting companies.
For example, the offshore Swift programmers I've encountered will add "?? 0", "?? []" etc. into expressions involving optionals until they compile. That doesn't mean that Swift's nullability is pointless, it's still a great tool for diligent programmers.
Re: Swift Regrets
#166I 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.
Xcode's faults preceded Swift by many years.
Re: Swift Regrets
#167Earlier quoted context omitted.
C++ pays an extraordinary price for the fully parallel builds, concealed in the "One Definition Rule". The price is, if you violate the ODR the standard says your program is not valid C++ (and thus has no defined meaning) but there is no requirement for a diagnostic (ie a compile or link error) and the build might complete. This has sometimes been described as "False positives for the question is this a program?" and…
Could you have ODR and proper warnings / errors handling the issue when it pops up without much penalty?
If we decide "Oh, but I do want to detect inconsistencies, my users would want me to warn them about that" then we can't have the parallelization because we need to rendezvous constantly to verify the definitions are consistent.
There are a bunch of tricks that people do today to get some semblance of ODR checking for not too high a cost, and to avoid some ODR pitfalls that might defeat the checks they have. C++ programmers have accepted this danger, if you don't like it then C++ isn't the language for you.
Re: Swift Regrets
#168Earlier quoted context omitted.
A well jelled team, with senior engineers can be much more productive with Objective C. But for beginners, swift looks less intimidating due to its syntax familiarity. The language pitfalls become apparent as you dive into it. Perhaps that’s why swift in ML and other areas failed. People don’t like the language. In iOS you are forced to use it. I hope the swift team does some hard thinking and start slashing features…
This just isn't true. Given equal familiarity, Swift will be vastly more productive at any skill level. Of course you can always tunnel deeper into more sophisticated solutions using Swift, since Obj-C lacks most of its capabilities, but that's hardly an equal comparison.
Re: Swift Regrets
#169I guess I was in the minority who loved Objective-C and it's selector syntax. I think my main objection to Swift is that it seems to be written by people who hate Objective-C and made the calling syntax much more complicated. I dearly wish a more mature F-Script had been the next Apple language. A lot of the other problems is Apple not providing good documentation and making sure sample programs continue to compile.…
Re: Swift Regrets
#170Moreover, if you also consider that Swift heavily uses type inference (if a compiler is allowed to infer something, your brain will have to as well, when you look at the code) and includes lots of edge-case syntactic variation (say, multiple trailing closures) or special-purpose features (say, SwiftUI builders), it is no wonder that even an advanced programmer can look at a piece of Swift and go: "WTF does this thing even do??". On top of all that, add a complicated generics system (i.e., Protocol-Oriented Programming) with conditional interface adoption and default implementation inclusion and you get a Frankenstein that only Apple fanatics can love.
Swift seems to be great for only two kinds of programmers: the small snippet "Hello World" crowd and absolute Swift experts. Intermediate programmers probably just get lost in the language with a sinking feeling.
Regardless of the fact that I have over 10 years of C++ under my belt, I experienced so much unexpected, recurring frustration with Swift over the course of a couple of years that I started migrating away toward Python. The devotion to simplicity, predictability and elegance expressed by the Python community feels, by comparison, revitalizing to me.
Not a rant, just my $0.02.