15 ms·
As someone who always disliked Objective C, I think Swift looks very promising. I'll check it out right away :) Software-wise, I feel these current WWDC announ
by Udo 12y ago
As someone who always disliked Objective C, I think Swift looks very promising. I'll check it out right away :)
Software-wise, I feel these current WWDC announcements are the most exciting in years.
Looking at the Swift docs right now, I can see many interesting inspirations at work: there's some Lua/Go in there (multiple return values), some Ruby (closure passed as the last argument to a function can appear immediately after the parentheses), closure expressions, strong Unicode character support, a very very neat alternative to nullable types with "Optionals". Operators are functions, too.
It has the concept of explicitly capturing variables from the surrounding context inside closures, like PHP does, instead of keeping the entire context alive forever like Ruby or JS.
Hell there is even some shell scripting thinking in there with shorthand arguments that can be used as anonymous parameters in closures, like "sort(names, { $0 > $1 } )".
Inside objects, properties can be initialized lazily the first time they're accessed, or even updated entirely dynamically. Objects can swap themselves out for new versions of themselves under the caller's nose by using the mutating keyword.
There is the expected heavy-weight class/inheritance scheme which accommodates a lot of delegation, init options, bindings, and indirection (as is expected for a language that must among other things support Apple's convoluted UI API). But at least it's syntactically easier on the eyes now.
Automated Reference Counting is still alive, too - however, it's mostly under the hood now. Accordingly, there is a lot of stuff that deals with the finer points of weak and strong binding/counting.
Swift has a notion of protocols which as far as I can tell are interfaces or contracts that classes can promise to implement.
I think generally there are a few great patterns for method and object chaining, function and object composition in here.
The language has C#-style generics, and supports interesting type constraint expressions.
- seanalltogether 12y agoHe mentioned the desire to drop the "C" from objective-c, but I'm curious what this means for using c/c++ libraries now. Do they need to be wrapped by objective-c before being visible in swift?
- FreezerburnV 12y agoIt seemed like it could interoperate with C just fine based on the slide talking about all three. Also because it uses the Objective-C runtime and compiles to native, it might just see C functions as normal functions. Though what little I've looked at the free book hasn't given me any hints about that yet.
- Udo 12y agoI suspect that as long as it compiles to LLVM, anything goes.
- quonn 12y agoSwift uses a special "bridging header" to expose Objective-C code to Swift. This header will presumably be processed by the Swift compiler. In the other direction, XCode will automatically generate an Objective-C header to expose your Swift code to Objective-C.
- outworlder 12y agoThe ibooks guide references a "Using Swift with Cocoa and Objective-C" document. Is that where you got your information?
- deleted 12y ago[deleted]
- eevilspock 12y agohttps://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/BuildingCocoaApps/index.html https://developer.apple.com/library/prerelease/ios/documenta... For discussion: https://news.ycombinator.com/item?id=7837468 https://news.ycombinator.com/item?id=7837468
- sv3nss0n 12y ago"You cannot import C++ code directly into Swift. Instead, create an Objective-C or C wrapper for C++ code."
- pjmlp 12y agoI hope so. Another stab on C's back.
- DanielRibeiro 12y agoSwift's environment is also very similar to Elm's time travel debugger: http://debug.elm-lang.org/ http://debug.elm-lang.org/ Direct link to Elm's demo similar to Bret Victor's: http://debug.elm-lang.org/edit/Mario.elm http://debug.elm-lang.org/edit/Mario.elm (video: https://www.youtube.com/watch?v=RUeLd7T7Xi4 https://www.youtube.com/watch?v=RUeLd7T7Xi4)
- AlexanderDhoore 12y agoI immediately thought about that as well. I wonder how they pull it off? Swift is not a functional language, so they just save every single variable, or what?
- seanmcdirmid 12y agoTime travel debugging has existed for a long time, and it's not limited to functional languages; the most obvious way they could do this is through checkpointing.
- cwp 12y agoCheckpointing is a natural fit with the Cocoa API, which uses an event loop. Just save the state of the application after each event is handled.
- gtrak 12y agoJust a hunch, LLVM uses Static-Single-Assignment, which is just that, saving every single variable change.
- tptacek 12y agoI really don't see the Golang influence at all. The multiple- return- value semantic is closer to Ruby's than to Golang's; you're returning a tuple, which happens to have natural syntax in the language. Defining Golang features that don't exist in Swift: - Interface types with implicit adoption (Swift takes explicit protocols from ObjC) - Error types - Relatedly, the "damnable use requirement" and its interaction with error types and multiple value returns (ie, the reason Golang programs in practice check errors more carefully than C programs). - Slice types - Type switching (though, like Golang, it does have type assertions) - "defer" - Of course, CSP and the "select" statement. Swift features that don't exist in Golang: - Generics - Optionals - A conventional, full-featured class-model Of the languages you could compare Swift to, Golang seems like one of the biggest reaches. Even the syntax is different. (I like what I've read about Swift and expect to be building things in both Golang and Swift, and often at the same time).
- stcredzero 12y ago(I like what I've read about Swift and expect to be building things in both Golang and Swift, and often at the same time). How about a blog series where a developer implements something in Golang and/or Swift, then you explain how it's insecure? Then the developer tries to fix it and you explain something else that's insecure. Rinse, repeat.
- chc 12y agoI thought that was called "Hacker News comments."
- nardi 12y ago> - Interface types with implicit adoption (Swift takes explicit protocols from ObjC) Objective-C has informal protocols, and so does Swift.
- deleted 12y ago[deleted]
- tomlu 12y ago
- zenojevski 12y agoFrom a user's point of view, it's basically straight out of the Rust book, all the gravy with also relaxed ownership and syntax. It has it all [1]: static typing, type inference, explicit mutability, closures, pattern matching, optionals (with own syntax! also "any"), generics, interfaces, weak ownership, tuples, plus other nifty things like shorthand syntax, final and explicit override... It screams "modern!", has all the latest circlejerk features. It even comes with a light-table/bret-victor style playground. But is still a practical language which looks approachable and straightforward. Edit: [1]: well, almost. I don't think I've caught anything about generators, first-class concurrency and parallelism, or tail-call optimization, among others.
- kibwen 12y agoIndeed, I'm not sure what Swift's concurrency story is yet. Other than that it's encouragingly similar to Rust (we're evolving in the right direction!), but not quite as low-level.
- mkehrt 12y agoI'm sure that the main mechanism will be the existing dispatch queue libraries Apple's other languages use.
- Pacabel 12y agoThe similarity to Rust should scare the hell out of Rust's creators and proponents. Swift could very well render Rust almost totally irrelevant within the OS X and iOS sphere of software development. If we end up eventually seeing Swift implemented for other platforms, then the chances of Rust's long-term success diminish even more. Things might have been different had a stable, even if somewhat imperfect, initial version of Rust had been released by now, thus allowing it to gain some adoption and traction. I hope that the "But Rust isn't targeting those developers!" argument isn't used to try to justify this mistake, as well. Rust is already facing stiff competition from languages like Go, C++11, C++14, Scala and even Java 8. With the announcement of Swift, Rust's niche and audience are getting smaller, further preventing the widespread adoption that's necessary for a programming language to become truly successful.
- josephjrobison 12y agoIs it realistic to try to dive right in to the 500-page book they provided without a computer science background, just HTML/CSS/PHP self-taught experience, to learn the language? Or should I take other steps first?
- krenoten 12y agoReading a book cover-to-cover is, for me, a bad way to learn a language. I usually pick things up very quickly when I try to implement things using them that I am both familiar with and faced with annoying issues stemming to the language they are currently implemented in. If you don't have one of those, think about something you hate, and fix it with this. If the book is good documentation, then use it. But you may benefit from focusing more on problems than completing a book.
- lugg 12y agoJust read the first paragraph and conclusions if the have them, of each chapter. This will give you a good idea of what's there when you need it. Then I'd jump straight into tutorials. Honestly skimming 500 doesn't sound horribly hard to me. I've done that a few times to pick up something new. As ap said you won't learn the language like that but you will have a good reference to go and learn from after the fact. After that you could probably work through the examples in said book, or at least the interesting ones. P.S. above steps is all I really learnt from my cs degree.
- josephjrobison 12y agoAnd is this the exact same language - http://www.cs.cornell.edu/jif/swift/doc/index.html http://www.cs.cornell.edu/jif/swift/doc/index.html
- cschmidt 12y agoNo, it is completely unrelated. That is the other language called Swift.
- deleted 12y ago[deleted]
- curveship 12y ago> It has the concept of explicitly capturing variables from the surrounding context inside closures, like PHP does, instead of keeping the entire context alive forever like Ruby or JS. Just as a point of fact, javascript -- at least the v8 implementation I'm most knowledgeable of -- doesn't "keep the entire context alive forever." Only variables used in the closure are allocated into the closure (i.e. on the heap), the others are allocated on the stack and disappear as soon as the function returns. I don't use iTunes so can't read their book, but I wanted to ask: you say that ARC is still their GC strategy, correct? So reference cycles are still an issue? I'm surprised at this. I can see reference counting being a strategy for moving a non-GC'd language to GC (like Objective-C), but to start a new language with that constraint is surprising.
- Udo 12y ago> Only variables used in the closure are allocated into the closure I'm not sure that's true. Look at the following code: var x = 123; var f = function(xname) { eval('console.log('+xname+');'); } f('x'); It's a dynamically named variable. Clearly, f() has access to the entire context that surrounds it, not just the objects explicitly used in the function code. In this example, the compiler could not possibly have known I was going to access x. This means in Javascript, as well as in Ruby, when you hand a closure to my code, I can access the entire environment of that closure. Contrast that with Lua, for example, where the compiler does indeed check whether an outer variable is being used and then it imports that variable from the context only. PHP does it most explicitly, forcing the developer to declare what outer objects they want to have available within the function.
- Sheepshow 12y agoIn your example, X is still in scope when f('x') is called. It doesn't require closure to work.
- Udo 12y agoI think you misunderstand what I'm trying to say. The point is not that x should be out of scope (why would it be?) The original assertion by curveship was that the outer context is not kept alive for the function, and that f() only gets access to the variables it explicitly imports from the outer context. And I thought this might be wrong, so I cooked up the example. Again, this is not about scope. This is about the fact that the function itself keeps a reference to the entire context it was created in, as opposed to just the things it explicitly imports. In this, it appears, Javascript works exactly as Ruby, which again makes the entire outer context available through the binding facility. I'm sorry if that wasn't clear from my description.
- CCs 12y agoI think everybody can see their own favorite language in it... and that's a good thing. For me it looks like Scala + a sprinkle of C++14 :)
- anilmujagic 12y agoIndeed, I also think it's most similar to Scala.
- CCs 12y agoThere are others too with "looks like Scala": Jacob Leverich https://leverich.github.io/swiftislikescala/ https://leverich.github.io/swiftislikescala/ Den Shabalin http://www.scribd.com/doc/227879724/Swift-vs-Scala-2-11 http://www.scribd.com/doc/227879724/Swift-vs-Scala-2-11
- krsna 12y agoI agree that Swift looks quite promising, though I'm a bit surprised that it doesn't offer any concurrency primitives like Go does. I only say this because "The Swift Programming Language" e-book claims that "it’s designed to scale from 'hello, world' to an entire operating system."