THE SWIFT PROGRAMMING LANGUAGE

ONE WORD THE SWIFT IOSIFICATION OF CODE

there's already a thread you vessel for advertisment

>>2
well fuck me hard then

It looks like a decent language, I might make some iOS apps when it is available.

Clean is good enough for me.

So Apple doesn't allow you to choose a language to program in under the iOS? You have to use its pet languages? Fucking bullshit.

>>6
Sounds like you get at least some choice now. But Android is the same. [spoilers]There's the NDK but a lot of the API is missing so you still have to wrap it in Java.[/spoiler]

>>7
Are you doing that [spoilers] thing on purpose?

>>8
No, but I might start doing that now^!

>>7-9
Hey! this is an impoaster! a cloan! I am the one only one who has the right to [spoilers]

>>10
Why don't you just roal on outta here_�

>>11
I think you should hax my anus

app-le faggots stealing names

The Swift Parallel Scripting Language
http://swift-lang.org

>>6
Objective-C is a superset of C, so you can use C instead no problem. You guys love C, don't you? Buy an account for 99 bucks!

>>14

Objective-C is a superset of C

False!

>>15
Go tell that to Mr. Jimmy ``Jimbo'' Wales, faggot

>>13
This is nothing new. Apple always picks the names they want and lets their lawyers handle any conflicts with existing products. IOS, iPhone, probably others that I am unaware of.

>>17
Like the name Apple itself, court said it was fine because they weren't a music company, then they came out with the ipod...

looks like pretty much like groovy

Don't you guys find it just a little bit suspicious that the company is named Apple?

Influenced by Objective-C, Rust, Haskell, Ruby, Python, C#, CLU
OS iOS, OS X
License proprietary

A new era in software development. A game changer.

>>21
Yeah, that's the problem. It's a fine language otherwise. I'm not impressed by the xcode integration because it's just a fancy vendor lock-in. If that sort of thing was editor-independent that would be a different story.

From a brief look at Swift, it seems OK, but not novel enough to warrant creating an entirely new language.

IMO being proprietary is Swift's only reason to exist. If Apple wasn't obsessed with having dictatorial control over their whole platform, they could've put the resources they sank into Swift into something like Go or Rust instead.

>>23
The main designer is Chris Lattner (the LLVM/Clang guy) and he did look at Go and Rust. He said they influenced its design. The thing is, though, whatever language he offered to Apple, it had to be compatible with the Objective-C APIs, Grand Central closures, and all that other stuff they already had before making Swift. If you'd ever tried to use any of that stuff from a language that doesn't do things the Objective-C way, you'd know what a colossal pain in the ass it is to patch over the impedance mismatches with a bunch of bridge code, and how often you just end up rewriting your application logic in Objective-C classes. The best language for this was Ruby, but it wasn't really an improvement over Objective-C in terms of being able to write safe and expressive application logic.

>>24
I can see the influences from the list at http://nondot.org/sabre/ but when did he mention Go?

drawing ideas from Objective-C, Rust, Haskell, Ruby, Python, C#, CLU, and far too many others to list.

They always cite like a 1000 influences but their languages are so trivial they could be made out of just 2 or 3 of those influences by mixing and shaking their features. It's like saying that arithmetic was influenced by algebra, geometry, number theory and logic.

>>24

I wonder how a bunch of lisp and c programmers know about this.
Maybe you aren't in fact lisp and c programmers, just a bunch of appers.

>>27
Why did you point out a single poast then proceed to talk as if more than one apper had maid said poast?

>>25
Ah, it was somewhere else that he mentioned Go, long before Swift was announced, but I don't remember where and I have no idea how much of an influence it was. But he has used it.

>>27
No gods. No lispers. Only me.

>>29
That doesn't make it an influence. I'm sure he's also used one or more of: Lisp, PHP, Forth, Java, Tcl and so on, but I don't see their influence either.

In fact, the most likely resemblance to Go, protocols (vs. interfaces), more closely resembles virtually every other language with this kind of lateral subtyping feature (protocols, traits, roles, etc.) In Go, interfaces are structurally typed¹, but protocols in Swift are opt-in². Swift, Java, Rust, Perl, Perl 6, and PHP are all in that category and you admit mixins that adds Ruby, Factor and I believe CLOS. You get the idea.

1. https://en.wikipedia.org/wiki/Structural_typing
2. https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Protocols.html#//apple_ref/doc/uid/TP40014097-CH25-XID_345

I think he might have been influenced to avoid Go's idiosyncrasies. What they have in common seems to be mostly: has curlies, signatures, a type system. Types aren't even annotated by juxtaposition (thank god). I can't think of a single significant similarity and I suspect he might have even gone out of his way to avoid it.

>>29
Congratulations, you're fucking retarded.

>>30
Hey, man, I just wanted to point out that he's used Go, not claim that it was the basis of the whole language. At most, maybe one or two design decisions could be blamed on Go. The real winner here is Objective-C, to the point that 90% of the "surprising" things in Swift (like having inheritance at all) are there solely for the purpose of compatibility with the Objective-C object model. Protocols are among those features, so look no further. I'm not sure where the Objective-C guys got the idea though. Was it in Smalltalk? I don't remember.

>>32
You said he stated it as a design influence.

Protocols and friends are everywhere. ObjC was influenced by Smallktalk but I suspect the existence of protocols in ObjC were the result of an attempt to make messaging faster. I don't it in Smalltalk-80. I don't see why Smalltalk would want it, you could do it at runtime and objects were expected to handle messages dynamicaly anyway. Alan Kay said binding should be done as late as possible, so there's no point in defining an interface/protocol up front when the decision must always be made at runtime.

You're saying maybe one or two, but I would go so far as to say no design decisions based on Go, except perhaps by way of exclusion. I really am beginning to suspect a lot of things were thought best left out after experiencing Go. I know it gave me the "oh god no" feeling many times.

More like Smallcock lol

>>32
you're doubletalking and backpedaling so much you obviously have no idea about any of the shit you're saying
i think you just like how your words look when you write them on the screen
go back to writing flappy bird clones
the adults are talking

>>21
Apple™ does it again!
______________
Sent from my MacBook Pro™