Do they have a pdf book?
The Swift Programming Language
601–610 of 970 posts
Re: The Swift Programming Language
#602Earlier quoted context omitted.
Basically, he just came up with something using FP that was more demo-able than somewhat hacky things people were already doing in other languages/environments. (For which, he deserves tons of credit.)
Bret victor's demos really have nothing to do with FP. The textual code demos in his learnable programming essay are all JavaScript and fairly imperative.
[deleted]
Re: The Swift Programming Language
#603Enumerations (from: https://developer.apple.com/library/prerelease/ios/documenta... ): Unlike C and Objective-C, Swift enumeration members are not assigned a default integer value when they are created. In the CompassPoints example above, North, South, East and West do not implicitly equal 0, 1, 2 and 3. Instead, the different enumeration members are fully-fledged values in their own right, with an explicitly-defined…
Indeed. Luckily C++11 took care of the issue on the C++ side. http://en.wikipedia.org/wiki/C++11#Strongly_typed_enumeratio...
Do Swift's enumerations allow recursive definitions?
Re: The Swift Programming Language
#604Earlier quoted context omitted.
I think it uses the Objective-C runtime directly, so it has access to all the frameworks and Swift classes can be loaded into Objective-C projects as well. There are a few other languages that do this with the Obj-C runtime, for example a Lisp variant called Nu[0]. [0] http://programming.nu/
There's a Ruby implementation by a former Apple employee that does this as well: http://www.rubymotion.com/
Unfortunately it requires a $200 up front investment before you can even toy with the language. RubyMotion was my first thought when I saw the code happening on the keynote, but at least this will be free with the OS.
Re: The Swift Programming Language
#605As 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?
Re: The Swift Programming Language
#606Earlier quoted context omitted.
It is unethical to continue writing code in non-memory-safe C or C-based languages, for any purpose. Period. I'm looking forward to seeing your new operating system and managed runtime written entirely using garbage-collected languages!
Parent poster didn't imply that the replacement would be garbage collected, just memory safe, which is a pretty big difference. I think you will see it sooner than you may think, it seems the tide may be turning.
Alright, I missed that nuance. I don't think I've ever worked with a language that provided memory safety without garbage collection.
Re: The Swift Programming Language
#607Earlier quoted context omitted.
While half of the things you checked in that copy-paste are wrong, let me take the bait and say why it will work: - it's not just an arbitrary language, it's the new officially sanctioned programming interface for Apple's gigantic, wildly profitable ecosystem - it's much more concise than Objective-C - it's faster than Objective-C - it's safer than Objective-C - it has more features than Objective-C - ...yet it's ful…
There's no real objective measure for either 'conciseness' or 'safety', in general terms. Whether or not it's faster in the real world is yet to be seen, and creeping featuritis has never been the hallmark of a great programming language. It makes good press release and marketing speak, but those assertions are a long way from making the OP 'wrong'.
So you take a language with null pointers, unsafe pointer access, possibility of array and buffer overflows (C and Objective-C).
And then you take another where you have no null pointers, no direct pointer access, and no possibility for array and buffer overflows (Swift).
And you say "nah, I look at these two, and I can't objectively tell which is safer"? Are you fuckin' kidding me?
Regarding speed, it's been proven faster by benchmarks, and by the fact the very reason Swift doesn't mix C types and Objective-C types is so the compiler can better reason and optimize the resulting code.
Re: The Swift Programming Language
#608Earlier quoted context omitted.
It is unethical to continue writing code in non-memory-safe C or C-based languages, for any purpose. Period. I'm looking forward to seeing your new operating system and managed runtime written entirely using garbage-collected languages!
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.
Re: The Swift Programming Language
#609Earlier quoted context omitted.
I think this is much less to do with performance and more to do with safety. If anything can be nil, NPEs are a fact of life. If you're forced to annotate for the compiler which values can be nil, and then forced to handle the nil case when you consume them, the problem disappears.
I don't think the problem disappears so easily. It puts a signifiant burden on the programmer (on the top of my head, if I have a set of 20 properties in an object, all optionals, I'll have to unwrap them all, even if I can guarantee by knowledge of the data that they're not nil), it will still throw an error if a value became nil after the test, and there is still the implicit unwrapping system that would cause runt…
I was looking through the programming language referenced that was published and the patterns that it uses to deal with Optionals isn't that bad. Having the question mark helps a great deal as a mental check when comparing syntaxes.
In my opinion, having that as a language rule will probably force people to design their classes to have things set at initialization more often than not.
Re: The Swift Programming Language
#610Earlier quoted context omitted.
According to one Apple developer who works on the project it will _likely_ be open sourced, though the developer says they don't know if that's true or not: http://forums.somethingawful.com/showthread.php?threadid=363...
Could you post the message (or thread) somewhere? I think that post is paywalled.
Sure, sorry - I'm not sure which SA threads are free and which require payment. This is the relevant bit:
"Is this under NDA?
No.
Is this open source?
Not yet. It probably will be, but I can't make promises. Right now, our repository still has a lot of history that we don't want to make public, and we have a lot of work to do before we release."