Live data from Hacker News

Swift Regrets

belkadan.com

41–50 of 207 posts

Re: Swift Regrets

#41
post #27

Earlier quoted context omitted.

I think that apple hated that at the end of the day, a lot of the system frameworks had to be written in objective-c++ which is not great.

NeXT had another point of view on that matter though, the original DriverKit was Objective-C. Objective-C++ main point of existence, just like POSIX, was only to bring other software into the platform. It is quite telling that only old timers have access to Objective-C++ docs.

Are you and GP talking about the same thing?

The obj-c drivers from next/OpenStep were replaced with a restricted subset of C++ (not objective-C++) IOKit system. I'm not sure what system GP is referring to based off Obj-C++ but I assume it's not the drivers?

Re: Swift Regrets

#42

Earlier quoted context omitted.

I've found similar results, although at the end of the day, iOS development is still faster overall. Kotlin does a better job of getting out of the way when you need it to (compared to Swift), and Jetpack Compose is the real game-changer in terms of productivity. That being said, there's a lot that you 'get for free' in iOS' frameworks, and APIs are generally more interoperable / batteries included. Both of these fac…

I haven't had a chance to use Jetpack Compose yet but this roughly tracks with my experience. Needing to hunt down third-party libs for everything slows development down considerably and makes for complications down the road when those libraries inevitably stop being supported.

Totally.

To add to this: when looking for third party libraries (Swift/Objective-C or Kotlin/Android Java), aside from those from large organizations (Square, Airbnb, etc.), I've found the selection and quality of those available for iOS to be better, on average.

Re: Swift Regrets

#43
post #11

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 think my main objection to Swift is that it seems to be written by people who hate Objective-C I mean that's the vast majority of people >and made the calling syntax much more complicated. How is this true? Swift is very straightforward, and similar to other languages Meanwhile Objective-C is slow, unsafe by default, with super ugly syntax only a mother could love. More than half of Apple's CVE/iOS vulnerabilitie…

How is this true? Swift is very straightforward, and similar to other languages

That's the argument, most people want to program in JavaScript or C++, learning is such a bother. The Swift syntax is more characters than ObjC's syntax.

Re: Swift Regrets

#44
post #35
post #28

Earlier quoted context omitted.

I have a lot of experience in both languages, and TBH it's just not true. I'm less productive in swift in many ways, mostly because of it's slow build and indexing times. It's infuriating. You are still coding against the same UIKit and other apple libraries in both. SwiftUI has a chance to make it better, but it's incomplete and has bugs/gotchas that make it not as productive as UIKit when you run into that, which i…

It would be impossible to evolve Obj-C to add most of Swift's capabilities unless you drop binary and source back compatibility. At that point it's just another new language and you've lost the things you say made Obj-C simpler. I have a hard time believing any engineer is productivity bound by Swift's build times and especially indexing times, since indexing doesn't affect your ability actually write code. Typically…

I see you haven't worked in a swift code base that is more than a few engineers. Work in a project that is 20-80+ engineers and you slam into these issues very quickly. Last time I checked the inflection point starts around 100k lines of code.

Also 'thinking' of solutions often involves writing something and then trying it out in a build-edit-run cycle, and then integrating your thing into a larger app context, which also involves many build-edit-run cycles. Most people do not think of their solution in whole cloth in their head other than in a broad strokes manner and then start writing code. This means indexing and building matters greatly for actual productivity.

Indexing issues means your ide is not auto completing, click to definition doesn't work, and in the past, even syntax highlighting failed. Also when you have some half formed code, a lot of indexing functions start breaking in an annoying way, while I don't really recall this behavior in Objective-C code bases.

In practice I've found swift being 'able to catch issues more' is mostly strict nullability, better array / dictionary strictness and enums, which would actually be relatively simple to implement in an extended ObjectiveSwift. Strict generics would be more work, but you can add it to the language also as a version update. Dart showed how it's possible to add big changes like strict nullability to a language with their dart v1 -> v2 update. Objective-C could have gone down that path instead.

Re: Swift Regrets

#45
post #7

Before Swift/Kotlin our iOS team was way more productive than android. Everything was done in half the time. They both switched to new languages. Now it has flipped. Android does things in half the time the other team needs.

I find it hard to believe that anybody is faster coding in objc than swift, if you control for garbage code. It was easy to quickly write buggy messes in objc - swift made that a lot harder, and is also a much more ergonomic and productive language in my experience. I feel like there has to be some other factors at play if that’s the results you’re seeing. (Source: I’ve been doing objc since 2009, and swift since ver…

I code several times faster in ObjC than Swift, and this is after writing two released Swift apps. Just a simple thing like writing string to num to string that works in different bases is a nightmare in Swift.

Re: Swift Regrets

#46
post #11

Earlier quoted context omitted.

> I think my main objection to Swift is that it seems to be written by people who hate Objective-C I mean that's the vast majority of people >and made the calling syntax much more complicated. How is this true? Swift is very straightforward, and similar to other languages Meanwhile Objective-C is slow, unsafe by default, with super ugly syntax only a mother could love. More than half of Apple's CVE/iOS vulnerabilitie…

How is this true? Swift is very straightforward, and similar to other languages That's the argument, most people want to program in JavaScript or C++, learning is such a bother. The Swift syntax is more characters than ObjC's syntax.

C++ is of course a vastly more complex language than Swift. I don't think anyone would want to code in C++ these days if they can avoid it.

Re: Swift Regrets

#47
post #11

Earlier quoted context omitted.

> I think my main objection to Swift is that it seems to be written by people who hate Objective-C I mean that's the vast majority of people >and made the calling syntax much more complicated. How is this true? Swift is very straightforward, and similar to other languages Meanwhile Objective-C is slow, unsafe by default, with super ugly syntax only a mother could love. More than half of Apple's CVE/iOS vulnerabilitie…

How is this true? Swift is very straightforward, and similar to other languages That's the argument, most people want to program in JavaScript or C++, learning is such a bother. The Swift syntax is more characters than ObjC's syntax.

> The Swift syntax is more characters than ObjC's syntax. How so?

Re: Swift Regrets

#48
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…

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 is a pretty serious penalty to pay for the benefit of improved compile time.

Re: Swift Regrets

#49
post #11

Earlier quoted context omitted.

> I think my main objection to Swift is that it seems to be written by people who hate Objective-C I mean that's the vast majority of people >and made the calling syntax much more complicated. How is this true? Swift is very straightforward, and similar to other languages Meanwhile Objective-C is slow, unsafe by default, with super ugly syntax only a mother could love. More than half of Apple's CVE/iOS vulnerabilitie…

How is this true? Swift is very straightforward, and similar to other languages That's the argument, most people want to program in JavaScript or C++, learning is such a bother. The Swift syntax is more characters than ObjC's syntax.

No it’s not. If you have multiple parameters Obj-C is much longer and ugly.

Re: Swift Regrets

#50
post #21

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.

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.
Post reply on HN