Live data from Hacker News

The Swift Programming Language

developer.apple.com

401–410 of 970 posts

Re: The Swift Programming Language

#401
post #37

I'm not even an iOS developer but this is by far the most exciting thing I heard in the keynote. As an amatuer/hobbyist programmer who's self-taught with Ruby, JavaScript, etc., the one thing that was keeping me from experimenting with iOS apps was Objective-C. I know I could tackle it, but it's been hard to take the plunge. I don't know much about Swift yet, but from what I've seen it looks very exciting. So if Appl…

I don't get the hate. Yeah, syntax is unfamiliar, bu once I got used to it I began to really enjoy objective-c. Ymmv etc., but it's now one of my fav languages - though I guess this is mostly due to cocoa

I also really like Obj-C now that I am familiar with it. I think the biggest pain point with iOS apps is understanding the way to build apps within the context of the iPhone (how to structure views, and the custom things like alert sheets, etc...) particularly if you are coming from a web app background. The syntax is quite nice (although sometimes verbose) once you get used to it.

Re: The Swift Programming Language

#402

What i don't really see in the docs is how to calls to objective-c methods are sorted out. For instance, if I have an objective-c class with a method -(void)addNumber:(NSNumber*)num withString:(NSString*)str; How is this called in swift? Is it myobj.addNumber(42, withString:"Hello World")?

The whole function name is addNumber:withString:

so if it has to be something, it might be myobj.addNumberWithString(42, "Hello world")

Re: The Swift Programming Language

#403
post #2

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

I 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).

Re: The Swift Programming Language

#406
post #83

“You also don’t need to write semicolons at the end of every statement.” Please. Please. PLEASE don't be whitespace delimited!

Please. Please. PLEASE don't be whitespace delimited! One of the prime examples I give for how HN/reddit has gone downhill was being downvoted by some clueless hipsters for suggesting that it would be easy to cross-compile from a whitespace-delimited language to a non-whitespace-delimited one. It's not some kind of huge fundamental divide in languages. For any non-whitespace delimited context free language, it should…

That does not sound like a practical solution for any language that offers a standardized toolchain or no explicit compilation as features. For those languages adding a homebrew translation step results in discarding unrelated features that the user might have wanted, and completely isolates you from intermingling your code with the rest of the language community.

Syntax is not the most important thing in a language but it's not nothing either.

Re: The Swift Programming Language

#407

Earlier quoted context omitted.

No. If you take the attitude that you're only covered if you use the concurrency primitives correctly, then you don't need atomic reference counting for everything. Basically, the programmer can use CSP to ensure that only one thread is messing around with any given section of the heap at a time, and the language implementers could say you're SOL if you do otherwise. (That probably isn't the Apple way, though.)

Swift uses the Obj-C runtime and interoperates with Obj-C code. Those languages assume a shared heap. If Swift modules didn't perform atomic reference counts, that would quite likely break Obj-C code operating on the same heap.

It should still be possible to have the compiler interpose mechanisms between everything else and the Swift code, such that your Swift code has a section of heap all to itself. By the time you're done with that, you're halfway to having implemented your own Erlang on the Obj-C runtime. That might be worth doing, though.

Re: The Swift Programming Language

#408
post #289

"The company says that Swift apps are significantly faster than Objective-C apps, outperforming them by over 93x." With a graph showing ObjC at 127x faster than Python, Swift 220x faster than Python. Thus the conclusion is 220 - 127, Swift is 93x faster than ObjC. Someone needs to resit their GCSEs.

[deleted]

Re: The Swift Programming Language

#409

So it looks like the language isn't open source and won't target non-Apple runtimes? I'm not trying to troll, I just think that it's a pity that Apple tends to limit the ecosystem and applications of its otherwise-great languages. Building against LLVM ought to make it fairly trivial to make this cross-platform.

There's no indications yet that it won't be. I suspect a large part of it will be part of a timed-release with their next merge to LLVM. But only Apple knows for sure.

Re: The Swift Programming Language

#410
Swift looks promising and looks like a step in the right direction. However, looking at the reference and everything, I fail to find an answer to this question. Does the concept of private members (methods and variables) in Swift's object system not exist? It looks like every single variable is exposed fully without any way to prevent it from being so.
Post reply on HN