|
What is Swift? Swift is a statically-typed, fully-statically-compiled, small-runtime programming language currently under development by Apple. Syntactically, it looks kind of like C except that most declarations start with a keyword like "var", "let", or "func" instead of a type name. So actually it looks a lot like Rust. Swift code:
The Swift compiler is directly integrated with Clang, so Swift code can directly interoperate with C and Objective C by simply importing or exporting a header. C++ support is a goal. If you are a PL geek, Swift's type system is essentially similar to Pierce's System F<, except with limited user-defined conversions, which means it is actually quite different in some fundamental ways but never mind. I would be happy to answer any questions you have about Swift here.
|
# ? Jun 2, 2014 19:45 |
|
|
# ? Apr 28, 2024 22:13 |
|
Is this under NDA? No. Is this open source? Not yet. It probably will be, but I can't make promises. Right now, our repository still has a lot of history that we don't want to make public, and we have a lot of work to do before we release. Your decision to parfolate the quanazores sucks, and you suck, too. In 1987, I was studying in Cypress with Don Woods when we decided to visit Mt. Athos, where . . . and then . . . Riemann integration . . . so the waiter said . . . quartic roots . . . anyway, the five of us finished the paper that night over the last of the hashish, and as I recall it clearly demonstrated that quanazore parfolation is deeply hosed up, and you should have consulted with us before ruining your language forever. Nothing is ruined. Swift has not yet committed to any measure of source compatibility. Even for 1.0, we are only committing to produce tools that will (to the greatest extent possible) automatically update your code to be compatible with the 2.0 language. So we have plenty of time to consider proposals like this. How do I iterate over all the values in an enum? It's a great idea, and it's something we want to do, but we haven't had time for it yet. rjmccall fucked around with this message at 06:14 on Jun 18, 2014 |
# ? Jun 2, 2014 19:46 |
|
I absolutely refuse to use your language because (check all that apply): [ ] It's another loving object-oriented language. You're in luck! It's another loving object-oriented language. OO is a pretty great tool for code organization and namespacing, and abandoning it would be dumb. A lot of criticisms of OO are really about (1) the use of inheritance to achieve subtype polymorphism and (2) the abuse of subtyping to paper over other inadequacies in the language. We generally agree with both of those criticisms. Swift provides a rich protocol system which enables both subtype polymorphism (via existential erasure) and parametric polymorphism (via generic programming). Swift also provides a single-inheritance dynamically-dispatched class system. There are two reasons for this. The first is that protocols are inherently awkward to extend, which makes them bad at modeling the reality of classes that frequently gain new functionality in library updates. The second is that it's totally mandatory: Swift has a hard requirement to seamlessly interoperate with languages i.e. Objective C) with a single-inheritance dynamically-dispatched class system. [ ] It's another loving imperative language. At its core, yes, the basic metaphor of a Swift function is a series of statements to run, and we provide all the familiar C-like structured control flow statements. That said, we've found (and intended) that Swift encourages a fairly functional style, mostly because we've put a lot of effort into addressing various dumb things that push programmers towards an imperative style. Immutable locals are as easy to declare ("let") as mutable ones ("var"). Tuples and ADTs promote multi-value returns instead of out-parameters. Function values are convenient to create and work with. I think a committed functional programmer could do quite well if they can survive writing 'return' in a few places. But there is still mutable global state, so maybe not. [ ] It's another loving language with global mutable state. Yep. We have zero interest in making a programming language that can't support the basic infrastructure for GUI programming on our platforms. "You should be using FRP for that, let me cite you some papers" is not actually something we can work with. [ ] It has significant whitespace. It totally does. We didn't want a mandatory statement terminator/separator, so there you go. At least it's not indentation-sensitive. The informal motivating theme behind the whitespace rules is to at least be able to tell programmers that the reason we misparsed their code is that their code style sucks.
[ ] It doesn't have garbage collection in TYOOL 2014. Garbage collection is a fractal of systemic problems. GC is pretty awful for memory usage. All the sophisticated GC techniques to minimize pauses and improve locality seem to push up peak memory usage, often by quite a lot, which then evicts a lot of stuff that the system generally had a good reason to keep around. GC is not friendly to static compilation. Many GC algorithms need to do bookkeeping on every store of a reference. To statically compile, you either have to commit to a lot of bookkeeping details as ABI, or you have to emit every store as a runtime call. You can get great performance if you JIT-compile everything, but that comes with its own host of problems. GC adds massive nondeterminism. Good luck reproducing the conditions that led to that particular memory problem if your program isn't 100% native. GC prevents naive interoperation with any language that isn't sharing the GC heap. Simple conservative C collection works (and sucks), but can't be soundly extended to languages with finalization (i.e. all of them) without explicit and unnatural efforts to preserve objects while operating on their dependent data. rjmccall fucked around with this message at 19:48 on Jun 2, 2014 |
# ? Jun 2, 2014 19:46 |
|
Do you imagine this being used in production, or is it a research language?
|
# ? Jun 2, 2014 19:52 |
|
It'll be useable in production. It still has a lot of room for improvement, but we're supporting it as a first-class language. The main limitation here for practical development is that we're not promising source compatibility in 1.0.
|
# ? Jun 2, 2014 19:54 |
|
Suspicious Dish posted:Do you imagine this being used in production, or is it a research language? The WWDC presentation certainly suggested to me that it's intended to replace Objective C entirely in a relatively prompt timeframe.
|
# ? Jun 2, 2014 19:58 |
|
It's not like we're dropping Objective C. We think Swift is a pretty great alternative, and we'd like it to eventually be center of development on the platform, but obviously there's a massive amount of code written in Objective C, and not only do we want to continue supporting that, but we also want to support seamless interoperation with it.
|
# ? Jun 2, 2014 20:02 |
|
Neat. How long has this been under development? Details on how generics work?
|
# ? Jun 2, 2014 20:03 |
|
https://itunes.apple.com/gb/book/swift-programming-language/id881256329 is the book mentioned in the announcement.
|
# ? Jun 2, 2014 20:05 |
|
I love you rjmccall.
|
# ? Jun 2, 2014 20:08 |
|
Uhh was that a time-reversing debugger in your pocket or are you just happy to see me? Seriously, is it recording state or using an Elm-style time-traveling debugger? Mutability vs immutability: yes. Generics: yes. I'm gonna dig in more but so far I like what I see.
|
# ? Jun 2, 2014 20:11 |
|
rjmccall posted:It's not like we're dropping Objective C. We think Swift is a pretty great alternative, and we'd like it to eventually be center of development on the platform, but obviously there's a massive amount of code written in Objective C, and not only do we want to continue supporting that, but we also want to support seamless interoperation with it. So long as Swift isn't unceremoniously dropped in two years like garbage collection in Objective-C (feel free to comment on that if you want), I'm happy to jump in whole-hog. Presumably since it's the same runtime and ABI (? or a transparent FFI) one could deploy compiled Swift on to old versions of iOS and OS X?
|
# ? Jun 2, 2014 20:13 |
|
What advantages do you think Swift provides over Objective-C?
|
# ? Jun 2, 2014 20:15 |
|
I'm interested. But I'm curious as to why?
|
# ? Jun 2, 2014 20:16 |
|
pokeyman posted:Presumably since it's the same runtime and ABI (? or a transparent FFI) one could deploy compiled Swift on to old versions of iOS and OS X? This is my big question about Swift.
|
# ? Jun 2, 2014 20:24 |
|
How do generics handle min(5, 5.1)? Mandatory casting to make the type inferrable?
|
# ? Jun 2, 2014 20:28 |
|
Doctor w-rw-rw- posted:Neat. How long has this been under development? About three years. Chris had hacked up a parser and crappy type-checker, but I was the first full-time developer/designer. The language has changed a lot since that prototype. Doctor w-rw-rw- posted:Details on how generics work? We can run generic code directly without instantiation; type metadata is passed so that you know how to allocate/copy/destroy arbitrary types.
|
# ? Jun 2, 2014 20:44 |
|
So, you can try Swift now, if you download Xcode 6 beta - which requires a dev account.
|
# ? Jun 2, 2014 20:52 |
|
pokeyman posted:So long as Swift isn't unceremoniously dropped in two years like garbage collection in Objective-C (feel free to comment on that if you want), I'm happy to jump in whole-hog. It's something that management believes very strongly in, and we're getting a lot of support. I think the odds that it'll be unceremoniously dropped are negligible. The politics around GC were always very different. pokeyman posted:Presumably since it's the same runtime and ABI (? or a transparent FFI) one could deploy compiled Swift on to old versions of iOS and OS X? We need a runtime on top of what the OS provides, but yes, we support deploying to at least the current set of OSes, and it's likely that someone could very easily make that work further back à la PLWeakCompatibility.
|
# ? Jun 2, 2014 20:54 |
|
Quoted from The Swift Programming Language iBook Does this mean you can't simply see if a boolean is true by doing something like if(trueBool){...} and requires to put YES or TRUE like if(trueBool==YES){...} ?
|
# ? Jun 2, 2014 20:56 |
|
LP0 ON FIRE posted:
No it means that only boolean values can be used like that. If you have an integer you need to go if(intValue != 0) etc but if trueBool {} is fine
|
# ? Jun 2, 2014 20:57 |
|
Suspicious Dish posted:What advantages do you think Swift provides over Objective-C? A better type system along a number of axes. Pointers are non-nullable, structs are equal citizens, tuples obviate a bunch of crap, there's a generics system, etc. The syntax is also a lot cleaner.
|
# ? Jun 2, 2014 20:59 |
|
Plorkyeran posted:https://itunes.apple.com/gb/book/swift-programming-language/id881256329 is the book mentioned in the announcement. quote:Requirements: To view this book, you must have an iOS device with iBooks 1.5 or later and iOS 4.3.3 or later, or a Mac with iBooks 1.0 or later and OS X 10.9 or later.
|
# ? Jun 2, 2014 21:02 |
|
Plorkyeran posted:How do generics handle min(5, 5.1)? Mandatory casting to make the type inferrable? Literals are overloadable with a default type. If the context suggests a better type, we'll use it; otherwise, we'll end up defaulting to Double.
|
# ? Jun 2, 2014 21:02 |
|
rjmccall posted:tuples Yes.
|
# ? Jun 2, 2014 21:03 |
|
Doh004 posted:I'm interested. But I'm curious as to why? We think Objective C is showing its age and don't feel that any other language really does what we want. Rust is pretty close, except for the memory model and the fact that we had (have?) no reason to think it wouldn't be an eternal research project three years ago.
|
# ? Jun 2, 2014 21:06 |
|
HTML docs: https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/Swift_Programming_Language/GuidedTour.html
|
# ? Jun 2, 2014 21:12 |
|
JHVH-1 posted:HTML docs: And Using Swift with Cocoa and Objective-C https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/BuildingCocoaApps/index.html
|
# ? Jun 2, 2014 21:14 |
|
I'm impressed there was no hint/leak of this until today. Gratz! e: I've been thinking of messing around with iOS apps. Should I just start with Swift and not bother with Obj-C?
|
# ? Jun 2, 2014 21:15 |
|
The keynote mentioned that Swift does away with 'entire classes' of programming errors. Could you elaborate on that a bit?
|
# ? Jun 2, 2014 21:17 |
|
rjmccall posted:The syntax is also a lot cleaner. Same for Brainfuck. I kid, but man Objective-C code is ugly. I think it's pretty cool that Apple is trying to improve their development environment and offer an alternative to Obj-C.
|
# ? Jun 2, 2014 21:19 |
|
Friend didn't see any mention of how threading or concurrency works in Swift in the book. Is there any word on how this is handled yet?
|
# ? Jun 2, 2014 21:19 |
|
Geno posted:I've been thinking of messing around with iOS apps. Should I just start with Swift and not bother with Obj-C? It's up to you. Learning Objective-C won't hurt. You'll mostly need to learn the APIs, and what you learn there will apply across languages.
|
# ? Jun 2, 2014 21:21 |
|
This is very impressive. Congratulations on having your work featured on pretty much the biggest stage possible.
|
# ? Jun 2, 2014 21:22 |
|
I'm not an iOS dev, so maybe this is a dumb question, but since there's no GC does that mean all memory management has to be done by the programmer?
|
# ? Jun 2, 2014 21:25 |
|
horse mans posted:The keynote mentioned that Swift does away with 'entire classes' of programming errors. Could you elaborate on that a bit? There's a bunch of things in this area. Our class pointer types are not nullable, but you can use a (very syntax-advantaged) optional type to add null back in a controlled way. We require variables to be "definitively initialized" before use, using a rule very similar to Java's but applied even to instance variables. Our equivalent of id does not implicitly convert to arbitrary types, although you can still call an arbitrary method on it with pretty minimal fuss. Generics don't define away dynamic type errors, but they can work to make them substantially less likely. Things like that.
|
# ? Jun 2, 2014 21:28 |
|
spongeh posted:Friend didn't see any mention of how threading or concurrency works in Swift in the book. Is there any word on how this is handled yet? It's something we want to put more language design work into, but frankly there were higher priorities. Right now, the story is pretty much the same as Objective-C, i.e. use GCD and other platform concurrency features.
|
# ? Jun 2, 2014 21:29 |
|
Damiya posted:I'm not an iOS dev, so maybe this is a dumb question, but since there's no GC does that mean all memory management has to be done by the programmer? It uses ARC, so memory management done by the compiler behind the scenes with retain counts.
|
# ? Jun 2, 2014 21:32 |
|
Bognar posted:I kid, but man Objective-C code is ugly. I think it's pretty cool that Apple is trying to improve their development environment and offer an alternative to Obj-C. This is what made me excited during the keynote. Every time I look at Objective-C code I feel like beating my head against the wall. It seems so drat complex unless I parse through every element, where with something like, say C#, it's much more readable. To be fair, my day job is ASP.NET C# web development, so that also affects it . But while I wait for Xamarin to update their Mono tools for iOS8, I really want to try this out. Maybe now I'll be able to start to write native code. That'll be cool .
|
# ? Jun 2, 2014 21:32 |
|
|
# ? Apr 28, 2024 22:13 |
|
Siguy posted:This is very impressive. Congratulations on having your work featured on pretty much the biggest stage possible. Thanks! We're all pretty excited. Damiya posted:I'm not an iOS dev, so maybe this is a dumb question, but since there's no GC does that mean all memory management has to be done by the programmer? No. Like Objective-C ARC, Swift has automated memory management using reference counting. You can think of it as a deterministic GC that's too stupid to collect cycles. Cycles can be manually broken using a weak reference or by explicitly reassigning one of the links in the cycle at a point when you know that's safe.
|
# ? Jun 2, 2014 21:33 |