Live data from Hacker News

The Swift Programming Language

developer.apple.com

921–930 of 970 posts

Re: The Swift Programming Language

#921
post #862

Earlier quoted context omitted.

> Why not use Ruby, or Python, or JavaScript -- or even Go, Rust, Clojure, or Scala? (Yes, I realize that the latter two run on the JVM, which would have been problematic in other ways.) Heck, they could have bought RubyMotion and made Ruby the high-level language of choice for development. Because OBVIOUSLY none of them solve the problems they wanted to solve (interoperabillity with Objective-C, fast, native, IDE in…

I'm not sure if you're kidding or not. IDE integration for a new language? They wrote it themselves. Do you think it would have been harder to integrate an existing language? Fast & native also also trivially solvable. I don't know about interop with Objective-C, that's probably the hardest part from your list. But complaining about IDE integration when they're also the creators of the IDE is... silly...

First, I like how you break apart the issues I raised (like "IDE integration") when I said that they wanted to solve ALL this problems at once.

So, even if just adding IDE integration for an existing language was easier than creating a new one, using an existing language wouldn't solve their other issues (e.g Obj-C interoperabillity with message passing, protocols, named parameters et al). And RubyMotion wouldn't permit all the optimizations they did, nor the kind of type safety they added.

>But complaining about IDE integration when they're also the creators of the IDE is... silly...

We're not talking about PyCharm level of IDE integration here. Not even about the current level of Obj-C/C++ integration XCode offers (for which they had to create LLVM tooling and LLDB to enable all the features they wanted to offer). It goes beyond that.

Re: The Swift Programming Language

#922

Earlier quoted context omitted.

That's really not a lot. The optional semicolons could also be influenced by BCPL or JavaScript.

Yeah, it's only the entire basic Syntax of the language they copied. Yes, Swift's semantics are different (since it's essentially a domain-specific language designed to make writing Cocoa apps faster), but syntax-wise a Go programmer feels right at home reading Swift.

>Yeah, it's only the entire basic Syntax of the language they copied.

Because, the keyword for function, keyword, parens-free conditionals and optional semi-colons are "the entire basic syntax" of Go, right?

Those are some of the most inconsequential details of Go syntax (all three of them), and of course all existed ages before Go.

Python has no semicolons and parens-free conditionals for one.

Re: The Swift Programming Language

#923
post #93

It seems like the only way to view the programming language documentation is on iBooks on an iOS device? For a programming book, this is ridiculous. Edit: The latest version of OS X does support iBooks. Lets hope you have that.

The contents of the book seem to be available here:

https://developer.apple.com/library/prerelease/ios/documenta...

Also some other useful stuff:

https://developer.apple.com/library/prerelease/ios/reference...

Re: The Swift Programming Language

#924

Earlier quoted context omitted.

It does not have features that often lead to bugs. E.g. the switch statement does not allow fall through and enforces a default case.

The lack of fall through makes me a bit sad since I think that it's a very powerful programming construct and it usually only hurts people new to the concept - but of course one can live without it.

Three things.

First of all, while you can't do this:

    case val:
    case val:
    case val:
        ...
You can do this in Swift, which does the same thing:

    case val, val, val:
        ...
Second, you can fall through in Swift, but you need to ask for it:

    case val:
        ...
        fallthrough
    case val:
        ...
So don't be sad.

And third... Seriously now, it's a "very powerful programming concept"? I bet 9 times out of 10 you use this very powerful programming concept in other languages, you did it by accident, not because you needed its pawa.

Re: The Swift Programming Language

#925
post #741

Earlier quoted context omitted.

My dislike is that it uses [] for method calls. It's like making Objective-English where we swap Z and A and j for o, just for the hell of it. If thzt sjunds like fun tj yju, thzn gj fjr Jboective-C.

This is in my opinion the best thing about Objective-C; it clearly delineates the object/class and C dichotomy, making it easier for a C programmer (or a Smalltalk programmer!) to pick up. For years, the only changes from vanilla C were the brackets, "#import" and the @ literal syntax (IIRC).

That's how I always felt. I liked the clear differentiation between C function calls and method calls on objects.

Re: The Swift Programming Language

#926
post #885
post #824

Earlier quoted context omitted.

While having some support for garbage collection is good, reference counting is not is a rather expensive way to implement that for applications. This becomes especially bad in multicores since it may dramatically increase the number of writes to shared object cache lines.

Wouldn't a lot of that be mitigated, though, by using tagged pointers in place of RC structs where possible? Seems like an obvious optimization.

Not really sure what the tag in the pointer would be used for. Could you give an example.

In general, reference counting has the problem that it needs to update the reference count. If you have a read-only data-structure these updates to the references will introduce writes that may severely impact performance since a write introduces cache consistency communication, while reads are communication-free.

Re: The Swift Programming Language

#927
post #739

I find it a bit sad that with all of the languages that already exist, Apple found it necessary to invent a completely new one -- and then make it proprietary. Why not use Ruby, or Python, or JavaScript -- or even Go, Rust, Clojure, or Scala? (Yes, I realize that the latter two run on the JVM, which would have been problematic in other ways.) Heck, they could have bought RubyMotion and made Ruby the high-level langua…

Probably because they wanted one that integrated well with their existing frameworks, and which really took advantage of their investment in LLVM.

Re: The Swift Programming Language

#928

My first instinct was to be cautious about new languages from Apple - Dylan was supposed to be something awesome until Apple cancelled it. But I only learned of the existence of Dylan years after it was cancelled. Looked awesome, but it was so niche I didn't want to spend time learning it. So I took a moment to look at why Dylan was cancelled.[1] Veryin interesting stuff. What it came down to was: - Apple was in dire…

You can mix Objective-C and Swift code in a project, so it would be easy to progressively port code one class at a time.

Porting NSView subclasses first would give you a win, because if you use Swift the classes can draw themselves at design time in Interface Builder. (Objective-C view subclasses just draw a white rectangle in IB.)

Re: The Swift Programming Language

#929

The documents for ios 8 show all examples in objective-c. Can't wait for them to be updated to swift. I'd love to start with 'getting started' and work my way through rest of the docs. I'm a programmer but could never stomach objective-c.

Some of the new docs I've seen let you select Objective-C, Swift, or both.

Re: The Swift Programming Language

#930

Me (running arch linux): Oooh! I'd love to learn a new language. And great, they have a free ebook it looks like to describe it! Apple: To download Apple Inc.’s 'The Swift Programming Language', you need to have iTunes. Me: What? Apple: Using a 64-bit edition of Windows? On a Mac? Me: No. That experience just killed a potential programmer for you right there, Apple. I had a few hours to kill, and was pumped to jump o…

https://developer.apple.com/library/prerelease/ios/documenta...
Post reply on HN