Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Swift Regrets

belkadan.com

Post reply on HN
Print view View original

131–140 of 207 posts

Re: Swift Regrets

#131

Post by dagmx »

w0mbat wrote: post #50
drclau wrote: 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.

AppCode uses xcodebuild etc under the hood and xcodeprojects to configure the ide. You aren't going to get any bugs in the compilation etc process than you would in Xcode.

Re: Swift Regrets

#132

Post by Apocryphon »

whiddershins wrote: post #111

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.

So long as interest in the language remains and Apple keeps pumping out incidental improvements to it as they update Swift, it will never be gone:

https://news.ycombinator.com/item?id=28623128

https://news.ycombinator.com/item?id=28582752

That, and the banal fact that large corporations including Facebook, Google, Netflix, Snap, Twitter, Pinterest, Spotify, Flipboard, and Apple itself continue to have large amounts of legacy code in Objective-C.

Re: Swift Regrets

#133

Post by fingerlocks »

apple4ever wrote: post #98
protomyth wrote: post #10

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 was there with you too. Objective-C may have been verbose, but it was readable and easily modifiable. It definitely seemed like the people who wrote Swift hated Objective-C. The "let", "func", etc syntax is ugly and unnecessary, along with the question marks. I know I'm swimming against the tide, but I'll be writing Objective-C for as long as I can.

> along with the question marks

I'd take the question marks any day over tracking a nil passed around a dozen source files before landing in a dictionary literal.

Re: Swift Regrets

#134

Post by fingerlocks »

protomyth wrote: post #52
jshier wrote: post #47

Earlier quoted context omitted.

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

well, no - Swift's call syntax actually results in the same or more characters: somePoint.moveBy(x: 2.0, y: 3.0) [somePoint moveByX: 2.0 y: 3.0]; somePoint.moveBy(x: 2.0, y: 3.0, z: 4.0) [somePoint moveByX: 2.0 y: 3.0 z: 4.0];

Now do a string format example

Re: Swift Regrets

#135

Post by whatshisface »

stephencanon wrote: post #120
saagarjha wrote: post #62

Earlier quoted context omitted.

> 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 vulnerabilities lately have been from parts of the OS that still use ObjC, Objective-C is quite fast–in many cases faster than Swift–and as (memory) safe as Swift for the most part. Most of Apple's CVEs come from code written in C or C++, not Objective-C.

> Objective-C is quite fast–in many cases faster than Swift–and as (memory) safe as Swift for the most part. Ehhhh. If you write Swift the same way you write Obj-C, it will generally be as fast or faster. You only fall off the happy performance path when you use Swift features that don't even exist in Obj-C. That's not Swift being slower, that's Swift letting you use abstractions that aren't possible in Obj-C. But yo…

>That's not Swift being slower, that's Swift letting you use abstractions that aren't possible in Obj-C. But you don't _have_ to use them.

What happens in practice is that the libraries you're consuming use them, and then you have to use them.

Re: Swift Regrets

#137

Post by fingerlocks »

w0mbat wrote: post #45
kennywinker wrote: post #12

Earlier quoted context omitted.

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.

Hope this eases your nightmares:

  String( Int("ff", radix: 16), radix: 10)

Re: Swift Regrets

#138

Post by mafalda »

My main takeaway is that Swift is complex and tries to solve many problems. As a result it is going to frustrate almost everyone in one bit or another.

I'm not an expert in the Swift Evolution process but I must praise it in terms of ease of reading. Back when I was invested in learning more about Swift, reading some proposals helped me understand it better. But I believe the Swift team/community will need to define a boundary some time in the future on what must be added or not to the language as its complexity grows. In the long run, even if a proposal makes sense, is implemented and was reviewed, it usually will also add a new thing to the language that implies in a bigger documentation and another way to code/solve a given problem.

In the AnyObject dispatch regret [0], the author wrote "As I’ve mentioned many times (though not so much on this blog), Swift had to be as good as Objective-C at making most Cocoa apps, or people wouldn’t use it no matter how good the new stuff was". My first real contact with Cocoa was while learning Swift and I can imagine all the hard work that was put into it. Then SwiftUI came on together with a bunch of new features to a language that I was still getting used to. After getting frustrated with the lack of documentation (combined with the lack of knowledge about some patterns) and no clear way to solve small problems while studying it, I've decided to dive again into Objective-C to not only grasp most of in one week but also to find that I did not need most of the features Swift delivered.

And this is something that is part of Swift. By design it offers you multiple ways to tackle your problems and by design it is only going to offer you more ways as time passes. I consider this a trait that is bad for the language itself in the long run. Looking back 7 years after the introduction of Swift I guess Apple would be better served if it just kept investing in Objective-C. But who knows what will Swift and its ecosystem look like in 2028.

[0] https://belkadan.com/blog/2021/08/Swift-Regret-AnyObject-Dis...

Re: Swift Regrets

#139

Post by selcuka »

kitten_mittens_ wrote: post #130
selcuka wrote: post #127

Earlier quoted context omitted.

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üß”?

There is no reason they can't come up with a more readable API that works. Python says it's 'ß' and I'm fine with it as long as it's consistent:

  >>> "Füß"[2]
  'ß'

Re: Swift Regrets

#140

Post by dep_b »

mpweiher wrote: post #108
zionic wrote: post #93

Earlier quoted context omitted.

This shouldn’t be true, ObjC’s only innate advantage is compile time, because the compiler is simply doing less and is capable of producing far worse (unsafe) code. At runtime Swift can utilize static dispatch, where objective C is mostly dynamic. Good swift code should generally be faster.

> This shouldn’t be true Performance isn't about what you believe should be true, but about what actually is true. Kinda like science. (versus religion) > ObjC’s only innate advantage is compile time Objective-C has a bunch of advantages. Compile time isn't really one of them, except when compared to Swift, which is ridiculously slow to compile. And there are languages with very comparable feature sets to Swift that…

Uber jumped on the bandwagon way too soon
Post reply on HN