41–50 of 145 posts
Earlier quoted context omitted.
I think Rust supersedes it in most aspects, especially in not being Apple driven.
So we’ll refuse go, typescript and react? Apple has the best engineering talent of all tech companies.
I hate to say this, but Swift is to Objective-c, what Scala is to Java.... It was very exiting and promising at first, but it became bogged down due to its sheer run-away complexity and over-academic approach to programming.... To an outsider, or iOS new comer, Swift looks much better than Objective-c, (due to Objective-c weird syntax), but to many insiders, Swift seems like a huge missed opportunity... The use of Sw…
For a language whose nearly exclusive use case is writing Cocoa applications, it’s odd how Swift ignored most of what had made Obj-C so good for GUI apps. Instead they just doubled down on everything that C++ was and Obj-C actively had tried to avoid.
Because I just started playing with SwiftUI/Combine without ever using ObjC/UIKit, I don't know what parts of ObjC shined.
I hate to say this, but Swift is to Objective-c, what Scala is to Java.... It was very exiting and promising at first, but it became bogged down due to its sheer run-away complexity and over-academic approach to programming.... To an outsider, or iOS new comer, Swift looks much better than Objective-c, (due to Objective-c weird syntax), but to many insiders, Swift seems like a huge missed opportunity... The use of Sw…
For a language whose nearly exclusive use case is writing Cocoa applications, it’s odd how Swift ignored most of what had made Obj-C so good for GUI apps. Instead they just doubled down on everything that C++ was and Obj-C actively had tried to avoid.
I can't really imagine Swift ever breaking out of Apple's walled garden. It's a pretty big garden, but the language concedes so much to Objective-C compatibility, it is hard to see any role for it where Objective-C never got a foothold. Where am I wrong?
curl -s " rel="nofollow">https://packagecloud.io/install/repositories/swift-arm/relea... | sudo bash
sudo apt-get install swift5=5.0.2-v0.4
Swift has come a long way. I remember first trying it and XCode acting like it couldn't figure anything out in Swift, and you could almost never bring up an autocomplete or search for references or jump to definitions or any nice feature in an IDE that worked just fine with Objective-C. I decided to give it another shot years later, and I'm working on a simple game in Swift right now, and it's been a much, much smoot…
Most of these all sound like improvements to XCode, not Swift?
I hate to say this, but Swift is to Objective-c, what Scala is to Java.... It was very exiting and promising at first, but it became bogged down due to its sheer run-away complexity and over-academic approach to programming.... To an outsider, or iOS new comer, Swift looks much better than Objective-c, (due to Objective-c weird syntax), but to many insiders, Swift seems like a huge missed opportunity... The use of Sw…
> That’s why Swift’s expressive and very lightweight syntax And a few paragraphs later: extension Array { func sorted ( by keyPath: KeyPath ) -> Self { sorted { $0[keyPath: keyPath] I can't say this is lightweight any longer. My greatest gripe with Swift comes not from Swift itself but from its standard library. When most new languages start with their own standard libraries that are usually interfaces towards C APIs…
> I can't say this is lightweight any longer. Swift optimizes for lightness at the call site, but even the definition is quite short for the constraints it imposes. > I recently needed to read some data from a file in Swift, and it took me quite some time to realise there was no fopen equivalent. You can import Darwin or Glibc to get direct access to fopen. It’s a bit unergonomic to use, though. > Read/write files is…
I'd have to look up how extension method would look in this case in C#, but my hunch is that it would be more lightweight and readable, with the same contstraints.
> You can import Darwin or Glibc to get direct access to fopen. It’s a bit unergonomic to use, though.
FileManager.default, .appendingPath etc. isn't ergonomic either ;)
> NSString, as a deprecated holdover from Foundation.
1. How is it deprecated if that's clearly the way to read/write files?
2. Foundation is the standard lib for Swift, and the way it's designed hurts Swift-the-language immensely, IMO. If that's deprecated, what's not deprecated and how can anyone figure that out?
> There’s also the nil-coalescing operator, but the whole point is that you can’t sweep an Optional under the rug.
There are several languages with Optionals, and they don't let you sweep them under the rug, and they provide better facilities to handle them.
IMO optionals the way they are (and a few other decisions) come precisely from the constraints of Foundation and original goals of Swift: to be a replacement for Obj-C when creating iPhone apps. That's why the NSStrings, and the awkward APIs, and the astonishingly large number of nullable parameters in API calls and nullable results from API calls.
Earlier quoted context omitted.
I'm pretty sure they went with Kotlin before Swift was open sourced, but I agree with you that the likelihood of them doing it is very low. Swift for Tensorflow hasn't gotten much traction because the overlap between programmers who know swift and machine learning engineers is super tiny. Making the core language differentiable sounds very promising though .
Swift was released before kotlin
Kotlin was open sourced around 2012 and people were using it in Android apps before Google officially started supporting it in 2016.
Earlier quoted context omitted.
For a language whose nearly exclusive use case is writing Cocoa applications, it’s odd how Swift ignored most of what had made Obj-C so good for GUI apps. Instead they just doubled down on everything that C++ was and Obj-C actively had tried to avoid.
Would you mind expanding on these feature sets a bit more? Because I just started playing with SwiftUI/Combine without ever using ObjC/UIKit, I don't know what parts of ObjC shined.
Earlier quoted context omitted.
Just to clarify Google's choice of Kotlin -- the maker of their IDE invented and did all of the heavy lifting with Kotlin, including building the JVM targeting compiler, and the IDE to develop it in (which is the foundation of Android Studio). Adopting Kotlin was very close to free for Android, and was really just rubber stamping what a lot of developers were doing regardless.
From what I remember Kotlin came to Android before Google embraced Jetbrains and Android Studio.
May 2017 - https://www.theverge.com/2017/5/17/15654988/google-jet-brain...
You could use Kotlin for years before Google officially endorsed it...given that Android Studio is made by JetBrains and they made it trivial to use. JetBrains did 100% of the heavy lifting, and Google just conceded eventually.