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

The Decade of Swift

swiftbysundell.com

Post reply on HN
Print view View original

21–30 of 145 posts

Re: The Decade of Swift

#21

Post by pavlov »

ardit33 wrote: post #10

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.

Re: The Decade of Swift

#22

Post by saagarjha »

dmitriid wrote: post #11

> 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 a function on String?

NSString, as a deprecated holdover from Foundation.

> There are a few other weird things in the language itself like guards which IMO are an entirely unnecessary construct that can be as easily solved with regular ifs.

That’s the whole point of syntactic sugar and constructs which make your intent clear.

> Or Optionals that have no way of working with them except unwrapping them (either with ! or via guards).

There’s also the nil-coalescing operator, but the whole point is that you can’t sweep an Optional under the rug.

Re: The Decade of Swift

#23

Post by cableshaft »

dmitriid wrote: post #11

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

The directory thing is more due to sandboxing than anything else. They don't want someone to be able to write an app that can read anything anywhere on your phone, so it has specific directories that have different levels of access and temporality (i.e. one is a temp folder that gets flushed each time you quit the app, if I remember correctly).

It's not that complicated once you look it up, and like most of this stuff, you can mostly write wrapper classes one time to hide the gnarly bits and call your wrapper class to do what you need to do the way you like to do it.

It's been several years since I've had it read from a file, and I actually thought I would click that twitter link and see something super complicated, but it's actually pretty straight-forward. Not a one-liner like some languages, no, but as soon as you want to open something with options (like the encoding in this one), most other languages start looking more complicated like this as well.

Like python's open looks more like this with options: "open(filename, mode='r', buffering=-1, encoding=None, errors=None, newline=None, closefd=True, opener=None)". I've opened many a file in Python scripts, but I'd have to look up buffering, encoding, errors, closefd, and opener right now if I wanted to use them (I haven't really in the past)

And Python has 11 different access modes that I often have to look up to remember what all my options are again: r+,w,wb,w+,wb+,a,ab,a+, and ab+

Re: The Decade of Swift

#25

Post by OberstKrueger »

ncmncm wrote: post #19

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?

Is this necessarily a bad thing? ObjC did fine as a mostly Apple-centric language. Swift is generally a lot nicer to use than ObjC, even if it wasn't a clean break from backwards compatibility.

Re: The Decade of Swift

#26

Post by gnachman »

ncmncm wrote: post #19

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?

One of my projects is pure Swift and I haven’t felt any Objective-C-based pain. Mostly this is because it doesn’t have a UI. When you touch UIKit then the legacy stuff rears its head and you have to deal with selectors and NSObject and such. I think SwiftUI is supposed to be the answer to that. We ought to know whether it works out in a decade or so :). But as long as you’re looking for a general-purpose programming language, Swift is a good choice. The type system is excellent and makes a lot of things easier. I like ARC better than GC, which is the biggest selling point in my opinion.

Re: The Decade of Swift

#27

Post by lazyjones »

Swift doesn't seem to be a bad language, but during my brief adventures with it I encountered a major drawback: differences between versions are so great, that searching the web for examples is problematic and you end up with many fruitless attempts and compiler errors. Apple's documentation isn't nearly as useful and readable as that of the Go team.

Re: The Decade of Swift

#28

Post by m_ke »

6700417 wrote: post #18
m_ke wrote: post #7

With Chris Lattner's move to Google and the state of Java it would interesting to see Google embrace Swift and add official support for it to Android.

This seems very unlikely to me. They would need it to interoperate with their existing stack. They chose Kotlin where they reasonably could have chosen Swift and then worked to extend it to work with their existing stack. Judging by what I would argue has been a lukewarm reception to Swift for Tensorflow, I think it would a very hard sell to convince people within Google to support Swift as a first-class language in…

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 .

Re: The Decade of Swift

#29

Post by Andrex »

cableshaft wrote: post #12

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?

Re: The Decade of Swift

#30

Post by endorphone »

6700417 wrote: post #18
m_ke wrote: post #7

With Chris Lattner's move to Google and the state of Java it would interesting to see Google embrace Swift and add official support for it to Android.

This seems very unlikely to me. They would need it to interoperate with their existing stack. They chose Kotlin where they reasonably could have chosen Swift and then worked to extend it to work with their existing stack. Judging by what I would argue has been a lukewarm reception to Swift for Tensorflow, I think it would a very hard sell to convince people within Google to support Swift as a first-class language in…

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