Live data from Hacker News

The Swift Programming Language

developer.apple.com

651–660 of 970 posts

Re: The Swift Programming Language

#651
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…

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

Re: The Swift Programming Language

#652
post #554

Earlier quoted context omitted.

I don't necessarily agree with the post you're replying to, but Rust is a memory-safe language without any garbage collection whatsoever. Proper unique pointers and move semantics are basically magic.

I'd be interested to know more about what you think of xenadu02's post. Practically, we can't completely stop coding in C/C++ yet, but a large class of software can be written in safer languages already, and it seems to me that once Rust is mature, we should strongly prefer it over C or C++. The security problems with non-memory-safe languages are really that bad.

What you're saying is perhaps ideal. The unfortunate reality, however, is that we really aren't seeing the "once Rust is mature" part actually happening.

There is still a large amount of change happening to the language and to the standard libraries. Some of this change has been of a here-and-there nature, where it's like they're trying to find an optimal or perfect solution that most likely does not exist.

C++11 (and C++14) may not offer the level of safety that Rust potentially could, but unlike Rust it's usable today, and using modern techniques does a reasonable job of avoiding dangerous situations.

It's been claimed that Rust will have stabilized and 1.0 will be released before the end of the year. Given that we're already into June, this becomes more and more doubtful each day. Now Rust is facing even more competition with this announcement of Swift. The longer we're forced to wait for a stable, seriously-usable release of Rust, the less viable Rust will become.

Re: The Swift Programming Language

#653
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…

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

Swift reuses the Objective-C runtime, so it had to be compatible in terms of memory management.

Re: The Swift Programming Language

#654
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…

Is 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?

The copy I have is only 366 pages, but it's 'converted' from the ebook so I'm not sure if that's a factor. A lot of the pages are dedicated to an examination of the grammar that's probably not relevant for a language overview and the rest is really readable and easily skimmed for interesting details. It's broken up with simple and clear examples every few paragraphs as well.

Definitely take a look through it. You definitely don't need to be a language nerd to understand it.

Re: The Swift Programming Language

#656
> you don’t even need to type semi-colons.

But you still need to type curly braces. Which are utterly redundant with indentation, pain to type, brainless task that languages should take care of, and a source of bugs.

Re: The Swift Programming Language

#657

I really wish we could play with it, without having to be a paid member. It's crazy how Apple is always so scared to release dev tools, at the end it will be out-there on bittorrent anyway...

Visual Studio isn't free in that regard either. What exactly are you comparing this release to?

http://fsharp.org/use/linux/ feel free to give F# a try. Apple hardware ( or MSFT tax) not required.

Re: The Swift Programming Language

#658
post #643

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…

I saw a lot of people mention ADT in relation to Swift but I haven't found examples in the documentation book I downloaded from Apple. Would you be kind enough to provide the example you saw? EDIT: My bad, page 40 in the section about protocols (unless I'm missing something).

Re: The Swift Programming Language

#659
Just glanced thru the Swift book in about 3 hours. Conclusion: all your programming language are belong to Swift, mostly stolen good ideas, some innovations, a few gripes.

I can say Swift takes inspiration and improves on at least these languages:

C:

typealias

struct

control structures

labeled statements AKA gotos

varargs

C++:

default arguments

class instance construction syntax

// comment

superclass, implementing protocol declaration syntax

semi-virtual class init, deinit

Go:

No parentheses around the condition part of control statements

Unicode identifiers

shorthand for signed and unsigned integer types U?Int(8|16|32|64)

C#:

in-out params

properties

subscript access of class member values

Objective-C:

ARC

protocols

extensions

param names as method names

willSet/didSet

nil?

Java:

enum

@final

super keyword

override method keyword

Scala:

Local type-inference, blend of an ML flavored FP with OOP without the noise and believe it or not, even more powerful in specifying generic type constraints. No stupid JVM type erasures either so you can actually create an instance of a generic type, just like C++ templates.

Self:

self

Python:

for i in enumerate(seq)

for key, value in dictionary

Type(value) explicit type conversion syntax

No public/private/protected class member access modifier bullshit

Array literals, dictionary is also like Python but use [] instead of {}

Ruby:

0..100, 100_000

Lisp:

closures

Scheme, Coffeescript:

? optional type modifier

Bash:

$0, $1... inside short callback closures

Innovations

---------------

break-less switch, optional fall-thru, comma as multiple case, case can be any value of any type, condition or a type constraint for pattern matching, supports method call shorthand

generic type constraint queries

overflow operators

@prefix, @postfix, @infix, @assignment modifiers for operator overloading Trailing closure as partial function application

Gripes

------

Seems like array[4..6] is even more useless than Javascript's Array#slice, and a far cry from Python's slices.

No set literals and list/set/dict comprehension.

Nothing for concurrency???? No yield, no generators, no channels, not even the synchronized keyword.

There's no decorator or annotations, and Swift isn't Objective-C, what's with the odd-ball @ modifiers?

I don't see namespaces as mentioned in the WWDC slides, and goto is definitely still here so you might just write another gotofail.

Looks like Swift is Apple's answer to Go, Rust, Scala, Java, PyObjC/RubyMotion, Unity, Xamarin and all these HTML5 + JS/Phonegap people. I'll definitely pay attention to Swift. If the performance results hold up, Swift + iOS8 will definitely leave Android's ancient Java 5 crap way out in the dust.

https://itunes.apple.com/us/book/swift-programming-language/...

Re: The Swift Programming Language

#660
post #651

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 your example, X is still in scope when f('x') is called. It doesn't require closure to work.
Post reply on HN