Live data from Hacker News

Swift Regrets

belkadan.com

141–150 of 207 posts

Re: Swift Regrets

#141
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.

Xcode as an IDE...and at a certain scale a build system like bazel or buck.

Re: Swift Regrets

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

> Honestly you would have gotten %80-%90 of the benefits of swift by making Obj-C use a new syntax that looked like swift and continued to improve Obj-C as a language than what you would have gotten with swift. A lot of the ugly of obj-c could have been translated away with very simple 1:1 syntactic sugar macros. This is a common talking point I hear in the Objective-C community, but nobody has come up with a credibl…

http://objective.st

Re: Swift Regrets

#143

Earlier quoted context omitted.

Hypothetical designs are bandied about all the time https://medium.com/@mattmass/the-alternative-reality-of-obje... https://twitter.com/tolmasky/status/1401972686037913601 https://mjtsai.com/blog/2014/10/14/hypothetical-objective-c-... https://web.archive.org/web/20141224114850/https://swiftopin...

“Hypothetical” being the key word here, though. These proposals are all thin on details, and if it was so easy someone would’ve made such a language by now.

http://objective.st

Re: Swift Regrets

#144
post #55

Earlier quoted context omitted.

That would not have helped with use-after-free, though, which Swift does solve.

That's solved by ARC, not Swift.

It was really solved by reference counting, way back when Foundation was introduced. The ARC increment was tiny.

Re: Swift Regrets

#145

Earlier quoted context omitted.

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.

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.

Re: Swift Regrets

#146
post #114

Earlier quoted context omitted.

“Hypothetical” being the key word here, though. These proposals are all thin on details, and if it was so easy someone would’ve made such a language by now.

That's a bit bad faith, making a language is never easy and takes a ton of resources. Swift is the bandwagon at Apple due to how Chris Latner started the project and his clout and I think it would be politically untenable to make ObjectiveSwift going against that, especially now at Apple. Nobody else but apple would make ObjectiveSwift too, because for better or worst ObjC & Swift are languages that are for the apple…

> Nobody else but apple would make ObjectiveSwift too, because for better or worst ObjC & Swift are languages that are for the apple platform and nothing else.

What about all the work done to support Swift on Linux? I had thought that was mostly done by the community rather than from Apple itself, but I could be wrong

Re: Swift Regrets

#147

Earlier quoted context omitted.

If you look at the original review videos (or even the keynote), you may notice that the first iPhone lags quite a bit. Of course, it's not Objective-C that causes it, but rather the limited hardware of the time.

It raised the bar a lot, at least. The lag was nothing compared to what you got on the typical Java-enabled flip phone, or the original Android G1!

Only for those that never had a Symbian or Windows/PocketPC phone on their hand.

Re: Swift Regrets

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

> > and made the calling syntax much more complicated. > How is this true? Swift is very straightforward, and similar to other languages Swift is objectively one of the most complex languages out there[1]. Just recently, they adopted basically the entirety of Smalltalk syntax as an edge case of an edge case[2]. Just the rules for initialisers are more complex than many languages and still don't cover all the cases[3]…

> The parts that make C dangerous, particularly strings and other raw pointer accesses are abstracted away behind safe NSString, NSArray, NSData and friends.

True, and just like in C++, the C tribe that came into the language just ends up using char * most of the time, instead of the safe variants.

Re: Swift Regrets

#149

Earlier quoted context omitted.

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.

I want. I do it. It gives me a level of control and a number of libs that no other language can give me, including all the C libs available as well. Yes, it is not pretty sometimes, but if you take a look at well-written C++ code you would be very surprised at how clean it can look. With its quirks from time to time, but very clean: - mark virtual overrides with override - use move semantics to increase performance -…

[deleted]

Re: Swift Regrets

#150
post #146
post #114

Earlier quoted context omitted.

That's a bit bad faith, making a language is never easy and takes a ton of resources. Swift is the bandwagon at Apple due to how Chris Latner started the project and his clout and I think it would be politically untenable to make ObjectiveSwift going against that, especially now at Apple. Nobody else but apple would make ObjectiveSwift too, because for better or worst ObjC & Swift are languages that are for the apple…

> Nobody else but apple would make ObjectiveSwift too, because for better or worst ObjC & Swift are languages that are for the apple platform and nothing else. What about all the work done to support Swift on Linux? I had thought that was mostly done by the community rather than from Apple itself, but I could be wrong

It is as successful as the work done to support Objective-C and GNUStep.

It is interesting that it works, and some folks might even create some products that use it, but it won't ever take the world by storm.

Similarly like Mono was never that much relevant, with Miguel and others ended up creating Xamarin and focusing on mobile instead.

.NET nowadays has a good story on Linux, because now it matters to Microsoft to make it relevant, and yet most UNIX shops would rather go with Java, Rust, Go,....

Post reply on HN