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

The Swift Programming Language

developer.apple.com

Post reply on HN
Print view View original

681–690 of 970 posts

Re: The Swift Programming Language

#681

Post by curveship »

Udo wrote: post #651
curveship wrote: post #629

Earlier quoted context omitted.

> 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), t…

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

> In this example, the compiler could not possibly have known I was going to access x.

Right, but it knew you were going to use eval, and to support that, it had to allocate all local variables in the closure. That's why you saw this behavior. The same would happen if you used a 'with' construct.

Re: The Swift Programming Language

#682

Post by ripter »

maaaats wrote: post #534
binarycrusader wrote: post #400

Earlier quoted context omitted.

You can actually read the language reference with a "standard browser": https://developer.apple.com/library/prerelease/ios/documenta...

Doesn't change pages when I click on stuff here.

Works for me in Chrome

Re: The Swift Programming Language

#683

Post by ScottBurson »

tptacek wrote: post #403
Udo wrote: 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 wit…

Multiple return values are, of course, much older than Ruby or Go(lang). The first language I used with them was Zetalisp (Lisp Machine Lisp) in 1979, though at about the same time, with the release of v7 Unix, C gained the ability to pass or return structs by value. Xerox PARC's Mesa appears to have had them a few years earlier. I don't know of any earlier examples.

I'm surprised not to hear Python mentioned, as it also has a tuple syntax.

Re: The Swift Programming Language

#684

Post by timr »

VeejayRampay wrote: post #639
creativeembassy wrote: post #62

Earlier quoted context omitted.

I spent a lot of time trying to do stuff with ObjectiveC, but just hated the syntax. That's been the biggest thing keeping me from developing Mac OSX apps; I just prefer Ruby's simplicity. I'm going to seriously give Swift a try.

Ruby is simple and beautiful, isn't it? Too bad it never got the shower of money from big backers Javascript, PHP and now Swift got blessed with.

Beauty is in the eye of the beholder, but Ruby is anything but simple. It has one of the most complicated syntaxes of any programming language in common use.

Perl and C++ are still in the lead, but with stuff like the gratuitous introduction of alternate hash syntax, new-style lambdas, etc., Ruby is catching up.

Re: The Swift Programming Language

#685

Post by e12e »

outworlder wrote: post #423
abruzzi wrote: post #88

Unicode variables, I love it: let 🐶🐮 = "dogcow" Moof!

The only practical use is that we can assign functions to a variable named λ Or define a type alias to that. On a more serious note, several languages have that, Ruby included.

It's not entirely useless to be able to use natural-language words/names for variables (if your language happen to not be English). For example when teaching kids how to code, why have proper spelling (eg: naming a "crow", "krake" rather than the proper "kråke") be an error? Just adds another barrier to learning.

I think we're approaching the level of unicode penetration that this shouldn't really be much of a problem.

Incidentally, I think this will be much more useful in Japan and possibly parts of China than in the parts of the world that speak an indo-european language (and therefore has an easier time learning English).

But, those areas that doesn't speak native English is of course just a small market. /s

Re: The Swift Programming Language

#686

Post by jernfrost »

angersock wrote: post #393
nlh wrote: 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'm not really that impressed--it looks like a hodgepodge of ideas from ES6, Ruby, Go, and maybe Rust, with a bit of backend work done to let it work on their existing infrastructure. I dislike that Apple has continued the special snowflake approach, that for some reason we as developers need to learn yet another different-but-almost-the-same language to develop for them, instead of just adding proper support and doc…

There is already MacRuby and RubyMotion. They tried using Java years ago. It failed. Developers didn't like it. Existing stuff simply doesn't mix that well with Cocoa and that style of programming. That is why something like Swift was needed.

I really don't get why you can bring up languages such as Rust and Go, and complain about Apple's special snowflake approach. Suddenly Apple is doing something developers have been demanding from them for years and something lots of other companies like Google, Mozila and Microsoft has already done. But oh no, because it is Apple, it is all wrong.

Re: The Swift Programming Language

#687

Post by Udo »

curveship wrote: post #681
Udo wrote: post #651

Earlier quoted context omitted.

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

> In this example, the compiler could not possibly have known I was going to access x. Right, but it knew you were going to use eval, and to support that, it had to allocate all local variables in the closure. That's why you saw this behavior. The same would happen if you used a 'with' construct.

> Right, but it knew you were going to use eval, and to support that, it had to allocate all local variables in the closure.

Wow, so there is actually special handling in the engine for this? So it does static analysis whenever it can, but not in these two cases?

Re: The Swift Programming Language

#688

Post by cschmidt »

josephjrobison wrote: post #641
lugg wrote: post #623

Earlier quoted context omitted.

Just 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. Aft…

And is this the exact same language - http://www.cs.cornell.edu/jif/swift/doc/index.html

No, it is completely unrelated. That is the other language called Swift.

Re: The Swift Programming Language

#689

Post by ekeren »

It is exciting, the language is full of modern stuff... This is what I catch at a glance of the book:

- Optionals (Java's @Nullable)

- Tupples

- Functions as first class citizens

- let vs var (immutable vs mutable)

- Operators are functions

- Closures

- Extensions (Adding things to an existing class)

- Value object (struct - are passed by value -- and so are Strings!!! )

- Reference Objects (class)

- Generics (lets hope it will be better than Java's version)

- External Parameters ??

- @final keyword (to prevent overrides - like Java's final)

It kinda looks like C# meets Ruby meets the let keyword Very complex...

And More

- object reference operator === and !==

- typealias (~ typdef)

- Optional Binding (if let x = y.f() { } else {}

- for-in loops (for i in 0...count)

- The default behavior of switch is not to fallthrough

Re: The Swift Programming Language

#690

Post by Pacabel »

kibwen wrote: post #643
Pacabel wrote: post #630

Earlier quoted context omitted.

The 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 ve…

Oh hello again, Pacabel. I'm familiar with your game by now. :) We're not scared in the slightest. I'll reconsider when Swift has inline ASM, allocators, linear types, move semantics by default, region analysis, and a type system that guarantees freedom from data races (oh, and when the code is open-sourced, and targets both Linux and Windows as a first-class citizen). Swift isn't intended to be a systems language: i…

My apologies, I didn't realize that expecting a programming language to have a stable syntax, stable semantics, a stable standard library and at least one stable and robust implementation before using it seriously in industry was merely a "game".

Perhaps this is news to you, but those of us who work on and are responsible for large-scale software systems tend to take such factors very seriously.

This may sound harsh, but it really doesn't matter what features and benefits Rust could potentially bring to the table if the lack of stability makes it unusable in practice today. A programming language that can't be seriously used might as well not even exist.

I don't doubt that Apple will have Swift available in a seriously usable form by this fall, and it's very likely that it will see rapid adoption soon after. I'm afraid I can't say the same about Rust and its supposed by-the-end-of-2014 1.0 release, given its current lack of stability and the rapidly-approaching end of the year.

Post reply on HN