Live data from Hacker News

The Swift Programming Language

developer.apple.com

891–900 of 970 posts

Re: The Swift Programming Language

#891

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

> break-less switch, optional fall-thru Like Go and Dart?

There's actually a new keyword called `fallthrough`.

Re: The Swift Programming Language

#892
post #52

"...we wondered what we could do without the baggage of C." Is that tongue in cheek? It's not even a particularly large, encumbered language, C.

I suspect they were referring more to the syntactic baggage in Objective-C – which is at least partially a result of the fact that ObjC was originally implemented as a simple C preprocessor. To avoid syntactic conflicts with C, ObjC uses lots of weird syntactic constructs that contribute to the language's characterization as ugly. A good example is the liberal use of the @ character to denote ObjC literals – even in…

That's good context, thanks. When I dabbled in Objective-C, I found the excessive bracketing strange. Thanks for the background.

Re: The Swift Programming Language

#893
post #52

"...we wondered what we could do without the baggage of C." Is that tongue in cheek? It's not even a particularly large, encumbered language, C.

Is that tongue in cheek? It's not even a particularly large, encumbered language, C. This would make a lot more sense if you knew about the history behind Objective-C. http://en.wikipedia.org/wiki/Smalltalk

That's a good point, thank you!

Re: The Swift Programming Language

#894
Swift is designed to make many common C and Objective-C errors less likely, but at least one class of bugs could be ascendant: off-by-one errors in ranges. Swift's ".." and "..." range operators are reversed compared to Ruby and CoffeeScript.

Swift's way is arguably more sensible: the longer operator makes a longer range. But switching the way two similar-looking operators work, as opposed to at least two other languages popular with the target audience, is bound to lead to errors as programmers switch contexts.

Just the fact of having the two operators in the language together is dangerous, since they look similar and switching them will lead to weird bugs instead of immediate compile-time or runtime errors. Switching their meanings makes this more pernicious.

Time to prime our eyeballs to look out for this one.

[1] Swift book: “Use .. to make a range that omits its upper value, and use ... to make a range that includes both values.”

Excerpt From: Apple Inc. “The Swift Programming Language.” iBooks. https://itun.es/us/jEUH0.l

[2] Ruby: "Ranges constructed using .. run from the beginning to the end inclusively. Those created using ... exclude the end value." [http://www.ruby-doc.org/core-2.1.2/Range.html]

[3] CoffeeScript: "With two dots (3..6), the range is inclusive (3, 4, 5, 6); with three dots (3...6), the range excludes the end (3, 4, 5)".

Re: The Swift Programming Language

#896
post #648

My thoughts while browsing the site: - function-level type inference much like Rust - no constness in the type-system (I like it) - class are reference types, structs are values types, much like D and C# - runtime dispacthed OO interfaces called "protocols". Blend the difference between runtime or compile-time polymorphism. Classes, structs and enums can implement a protocol. Available as first class runtime values,…

Trap on Overflow is not that expensive: http://www.sei.cmu.edu/reports/10tn008.pdf I am thrilled they did this. Implicit Overflow is the stupidest shit I know that everyone takes for granted. Also with CPU support it could be free, and adds negligible complexity to the silicon.

The part of that paper that says how expensive Trap on Overflow is:

> At the `-02` optimization level, our compiler prototype showed only a 5.58% slowdown when running the SPECINT2006 macro-benchmark. Although that percentage represents the worst-case performance for AIR integers (because no optimizations were performed), it is still low enough for typical applications to enable this feature in deployed systems.

Re: The Swift Programming Language

#897

A lot of commenters here are asking whether it will be open sourced, I'm curious, specific to those who think it should be open sourced: why? I'm not really curious about the philosophical reasons, but really the practical ones. How would Swift being open source help you as a developer? It's clearly targeted at iOS and Mac OS X, so does this mean you won't write Mac OS X or iOS apps if it's not open source, or did yo…

A reason in addition to ics’s two reasons: If Swift is open-sourced, it will be more popular, because it might be used by developers on other platforms too. Those extra developers would write more libraries and documentation that would improve the ecosystem of the language.

Re: The Swift Programming Language

#898

Earlier quoted context omitted.

the typing system seems to be from ecmascript as well var distance:Double = 70.0

This type annotation syntax comes from ML in the 70s (60s?).

Programmers here? But they haven't ever heard of BASIC? LET has been used for variables least since 1968.

Re: The Swift Programming Language

#899

Earlier quoted context omitted.

This type annotation syntax comes from ML in the 70s (60s?).

Programmers here? But they haven't ever heard of BASIC? LET has been used for variables least since 1968.

Hasn't it been used for binding in LISPs since the early 1960s? Swings and roundabouts.

Re: The Swift Programming Language

#900
post #797

Earlier quoted context omitted.

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

It's on the bottom half of the page about enumerations. Typically languages have product types, but lack true sum types. Swift's enums provide such leverage. That said, Swift's types are a bit less than recursive, so there's a bit of niggling still before you get to the affordances of something like Haskell's `data`.

Thank you.
Post reply on HN