Live data from Hacker News

Swift Regrets

belkadan.com

161–170 of 207 posts

Re: Swift Regrets

#161
post #155

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.

What in MSL is based on Objective-C?

Re: Swift Regrets

#162
post #156
post #145

Earlier 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.

I disagree. Knowing if something could be nil is a very different thing than something unexpectedly becoming nil. If you have values that are guaranteed by the compiler to never be nil, that removes the burden completely.

Re: Swift Regrets

#163
post #23
post #17

Earlier 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.

Lacking capabilities also means fewer decisions. If you want to model something in ObjC, it's a class, full stop. In Swift you have the choice between classes and structs. There are generally more degrees of freedom.

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

#164
post #161
post #155

Earlier 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?

Nothing and I haven't said otherwise.

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

#165
post #160

Earlier 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.

Fair enough, but I also don't see why we should judge languages based on the absolute worst projects written in them.

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

#166
post #6

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.

Xcode's faults preceded Swift by many years.

Some, yes. But in my experience, Xcode is/was amazingly responsive right until the first Swift file or IBDesignable class is added to a project. Then something happens in the background and everything starts to crawl.

Re: Swift Regrets

#167
post #60

Earlier 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?

No. ODR allows the compile step to be embarrassingly parallel. Since all the separate definitions of X are, by fiat, identical we needn't detect inconsistency at all and so there's no interaction, it's like merge sorting the files, you can spin up as many threads or processes as you like and process more source files.

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

#168
post #23
post #17

Earlier 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.

You’re correct, the post isn’t completely true- Swift syntax isn’t more familiar to beginners than ObjC is, because in their pursuit to take out the C, they also replaced several of the long-standing C patterns such as lack of prefix/postfix operators, standard for loops, parameter name and type ordering.

Re: Swift Regrets

#169

I 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.…

I didn't mind Obj-C, it had its own elegance and logic, and Apple really made strides in making it more ergonomic with features like ARC and of course the excellent xcode editor. I still miss using my apple mouse's horizontal scroll to navigate between files.

Re: Swift Regrets

#170
I think a part of the problem with Swift is Swift's community apparent devotion to the "look, ma, advanced Swift!" mentality. The shorter, the more compressed and the more arcane the code, the better programmer one is perceived to be. For example, I've been criticized by code reviewers for using simple, short if/else block runs, while convoluted, multiply-composed higher-order function chains with platform API mixed in were recommended instead, yielding entire micro-features that no part of a problem statement even asked for.

Moreover, 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.

Post reply on HN