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

Swift's Evolution

carpeaqua.com

Post reply on HN
Print view View original

51–60 of 105 posts

Re: Swift's Evolution

#51

Post by masklinn »

mikeash wrote: post #47
andybak wrote: post #40

Earlier quoted context omitted.

I agree. Looping over a numeric sequence is simply a specific case of looping over any collection. A language should reflect this. It feels so natural to write: for thing in collection: process(thing) and very easy to move from that to a functional style: map(collection, process) or collection.map(process) The number of times I also need a integer counter is fairly small.

When you do need an integer counter, the best way to have it is to create a new collection consisting of (index, element) pairs. Swift (and many other languages) make this easy: for (index, element) in collection.enumerated() There are some cases where the C style for loop is the most natural way to express something. For example, looping over NULL-terminated array of pointers is nicely expressed with one (Swift 2-is…

And you can trivially package the process into an iterator anyway if it's a case you encounter often.

Re: Swift's Evolution

#52

Post by plorkyeran »

mikeash wrote: post #45
jcizzle wrote: post #24

If you follow the Apple dev community, there is a group of folks that make their living on books and speaking. That's fine, but they are using the platform differently than someone shipping software. They are also often the authors of some of the more ideological, less pragmatic proposals. This has a large impact on the disconnect the author describes - which incurs a cost on folks who ship software. I do wish the Sw…

Maybe I'm in the wrong part of the Apple dev community, but I don't know of anyone who makes a living on books and speaking. I know many who write books and do a lot of speaking, but there isn't enough money in it for it to be anything more than a side gig.

Yeah, there's certainly some people who would like to make a living on books and speaking, but every single one of them that I know of has a job as an iOS (or macOS) developer of some sort and no one's even in the range where they can pretend that maybe one day they'll be able to quit their day job.

Re: Swift's Evolution

#53

Post by virtualwhys »

eggy wrote: post #10

Will Kotlin Native be able to compete with Swift on iOS? The syntax is very similar and it would make for a nice cross platform PL. I was holding off on Swift to see where it was going, but I'd like to add iOS to my dev targets. Objective-C was too verbose for me years ago, but I've heard it has changed a bunch.

Kotlin Native doesn't exist beyond pre-alpha software at this point, so the the question is a bit premature.

In 3-5 years Kotlin might be where Swift is now, but there's nothing guaranteed, just coming up with a GC solution alone is a gigantic engineering effort -- Kotlin, like Scala, Clojure, etc. all benefit from world class GCs, just by being hosted on the JVM. With LLVM you essentially start from scratch, same for porting Java libraries, there's a ton of work involved.

tl;dr; for now it's separate languages for iOS and Android unless you cut some corners with React Native to avoid writing the same app twice.

Re: Swift's Evolution

#54

Post by Apocryphon »

eggy wrote: post #10

Will Kotlin Native be able to compete with Swift on iOS? The syntax is very similar and it would make for a nice cross platform PL. I was holding off on Swift to see where it was going, but I'd like to add iOS to my dev targets. Objective-C was too verbose for me years ago, but I've heard it has changed a bunch.

I'm curious to see if the porting from Java to Kotlin on Android apps will prove to be as challenging- and frustrating- as people have described the shift from Objective-C to Swift.

Re: Swift's Evolution

#55

Post by tootie »

bsaul wrote: post #16

I'm actually pretty happy swift moves the server side story forward, because i'm convinced the "next big language" will have to run on mobile and server. Actually, i think they don't go fast enough, especially regarding concurrency ( which on the server goes beyond just providing async await, as lattner said they were aiming at something closer to the actor model). I don't think the "maybe objc is still relevant for…

I'm not a fan of Apple but I think I'd rather work with isomorphic Swift than JavaScript.

Re: Swift's Evolution

#56

Post by tootie »

bsaul wrote: post #16

I'm actually pretty happy swift moves the server side story forward, because i'm convinced the "next big language" will have to run on mobile and server. Actually, i think they don't go fast enough, especially regarding concurrency ( which on the server goes beyond just providing async await, as lattner said they were aiming at something closer to the actor model). I don't think the "maybe objc is still relevant for…

I'm not a fan of Apple but I think I'd rather work with isomorphic Swift than JavaScript.

Re: Swift's Evolution

#57

Post by coldtea »

nicky0 wrote: post #30
AsyncAwait wrote: post #28

I think the author misses the fact that Swift wasn't truly 'done' when it was introduced, (and still isn't). Objective-C had some 30+ years to evolve, but Swift can't have 3? I get that if you're shipping Swift in production you want to refactor as little as possible, but it is pretty hard to come up with the ideal design straight out of the gate. Swift can stop evolving, but it will be THEN when it loses the reason…

Anyone shipping swift code one day one had to be pretty masochistic. I just couldn't understand why people were doing it. It was obviously not ready for production use, and still isn't. But I'm happy that people are playing with it and the language is being refined so that I can start using it in a few years.

>Anyone shipping swift code one day one had to be pretty masochistic. I just couldn't understand why people were doing it. It was obviously not ready for production use, and still isn't.

Obviously because "production" is not some monolithic reality.

What's "production" standards for NASA or Google, might not be for some small team making an iOS app or an one-person indie shop.

They might prefer to experiment with the language in their app, and get a leg up on learning it starting from the initial release, even if there's gonna be pain.

Even for actual commercial code, the supposed "pain" this article mentions is really nothing to write home about.

Having to spend a week doing manual code changes because APIs were renamed is no biggie at all in the grand scheme of things.

Contrast with whole full blown languages and libraries used in production change completely or get deprecated/abandoned. Things from Microsoft inventing new stacks and deprecating others every few years, to J2EE dropping the crappy EJBs that tons of programmers had based their code on, to React Router being redone in a new style every year, to GTK/QT N to GTL/QT N+1 transitions, ...

Re: Swift's Evolution

#58

Post by coldtea »

nicky0 wrote: post #50
melling wrote: post #33

Earlier quoted context omitted.

Developers are shipping both small and large projects with Swift. You may have a different opinion, for reasons that you haven't stated, but shipping production Swift apps is not an anomaly.

It's fine if you don't mind using rudimentary, buggy tools, and converting your whole code base to the latest language changes every 6 months, and you don't mind bloating your app with a mandatory 8Mb runtime. Great for small projects, people coding for fun, learners, and early adopters/neophiles who enjoy keeping up with all the changes. But substantial projects need solid, stable tools. Swift will get there very so…

Great for small projects, people coding for fun, learners, and early adopters/neophiles who enjoy keeping up with all the changes. But substantial projects need solid, stable tools.

Lots of projects more important and substantial than anything you and I have worked on have been shipped with Swift. So that argument doesn't really fly. Apps redone/adopting Swift include Twitter, Pandora, Groupon, Fitbit, etc.

(Heck, major billion-dollar companies had built parts of their production infrastructure on Node when the thing was just on very early stages).

Re: Swift's Evolution

#59

Post by oscargrouch »

timjver wrote: post #14
AlexeyBrin wrote: post #3

The biggest problem Swift has is breaking changes from a version to another. Took me about 10 days to manually convert a Swift 2.5 project to Swift 3 to find out that Swift 4 will also introduce at least two breaking changes. I'm all for progress and modern ideas in a programming language, just don't break my old code!

They were pretty clear about this from the beginning... Sometimes you need to break a few things here and there to make it a more pleasant language for the decades to come.

And for the skeptics, C++ evolution is a strong statement for why keeping old cruft just for the sake of the early adopters maybe is not the right thing to do.

I prefer the Swift way, and had to move 2ish to 3ish code myself and it didnt suck that bad.

Re: Swift's Evolution

#60

Post by mpweiher »

mikeash wrote: post #45
jcizzle wrote: post #24

If you follow the Apple dev community, there is a group of folks that make their living on books and speaking. That's fine, but they are using the platform differently than someone shipping software. They are also often the authors of some of the more ideological, less pragmatic proposals. This has a large impact on the disconnect the author describes - which incurs a cost on folks who ship software. I do wish the Sw…

Maybe I'm in the wrong part of the Apple dev community, but I don't know of anyone who makes a living on books and speaking. I know many who write books and do a lot of speaking, but there isn't enough money in it for it to be anything more than a side gig.

I thought so as well, but apparently the Swift transition has enabled at least a bit of this. Yay! :-)
Post reply on HN