The live REPL is totally out of Bret Victor, very impressive.
Unsurprisingly, I looked at the screenshot, came back to this comments page and ctrl+f'd for "Bret".
The Swift Programming Language
501–510 of 970 posts
Re: The Swift Programming Language
#502Earlier quoted context omitted.
You can do this in C# (and presumably other languages). I've seen people using Greek symbols in mathy code before. It's kind of fun.
It's fun once. It's impractical for someone editing the code later though, I don't want to have to look up the unicode character each time I want to remember it, and I don't want to have to copy and paste it either, it's better to stick with the characters available on a keyboard.
OS X handles some of this by assigning mnemonics to keyboard keys with the meta key (on mac keyboards, Option, or the "windows" key on the standard layout) held down.
For instance, the registered trademark symbol ® is just option+r. ∑ is option-w. Diacritics are two-stroke combinations, to get é, you'd type option-e, which puts the ´ on the screen, and then type the e to complete the character.
Some of them definitely make more sense than others. ∑ looks like a sideways 'W", the trademark symbol is just a circled r, and the diacritic marks fit the character you'd commonly associate them with. (Guess what letter you hit to get ¨ over a letter?)
Beats copy/pasting out of character map, anyways!
Re: The Swift Programming Language
#503One thing I'm very interesting in knowing is how this affects the whole 'hybrid/web app' space. Many web developers (like myself) have used Phonegap/Cordova in conjunction with tools like the Ionic Framework for our apps, primarily due to the nearly esoteric (for some of us) nature of Obj-C, but Swift almost looks like JS, which certainly has motivated me to learn it and use it in future apps. I wonder if the aforeme…
(disclaimer: Ionic creator here): I think Swift will definitely get more people building iOS apps. But we still see a ton of demand from Ionic devs for Android support (perhaps more than iOS!), so unless the world moves 100% to iOS we think Ionic will still be incredibly important.
Re: The Swift Programming Language
#504Re: The Swift Programming Language
#505A lot of the syntax is incredibly similar to rust.
Yes, but Swift looks much cleaner thanks to ARC memory management. I wish Rust has something similar, all those sigils make it messy.
err.. Rust doesn't have neither '@' or '~' any more. And there is "std::rc::Rc" in case you want reference counting. A big fat difference is that you are not forced to use it.
Re: The Swift Programming Language
#506Swift has also pattern matching which I think is really awesome.
This is its greatest feature if you ask me... Imperative, classical OO language WITH pattern matching. It's a crazy world we live in.
Re: The Swift Programming Language
#507Earlier quoted context omitted.
Swift's environment is also very similar to Elm's time travel debugger: http://debug.elm-lang.org/ Direct link to Elm's demo similar to Bret Victor's: http://debug.elm-lang.org/edit/Mario.elm (video: https://www.youtube.com/watch?v=RUeLd7T7Xi4 )
I immediately thought about that as well. I wonder how they pull it off? Swift is not a functional language, so they just save every single variable, or what?
Time travel debugging has existed for a long time, and it's not limited to functional languages; the most obvious way they could do this is through checkpointing.
Re: The Swift Programming Language
#508Where are the low level lightweight concurrency/parallelism features?
Re: The Swift Programming Language
#509I found the notion of "Optionals" surprising and a bit hard to handle at first. In Objective C it was really easy to lazily allow values to be nil and still do things on them, so it's a bit of a departure. Thinking about it a bit longer, is it because of the clear distinction between non nullable values ans optionals that the compiler can optimise the code so much more ? (I am thinking about the xx times faster than…
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.
Re: The Swift Programming Language
#510I found the notion of "Optionals" surprising and a bit hard to handle at first. In Objective C it was really easy to lazily allow values to be nil and still do things on them, so it's a bit of a departure. Thinking about it a bit longer, is it because of the clear distinction between non nullable values ans optionals that the compiler can optimise the code so much more ? (I am thinking about the xx times faster than…
This might increase performance, but I'm pretty sure it's mostly there for safety. It forces the programmer to check for nil. It's like Haskell's "maybe" type.
Or Scala's Option or Java 8's new Optional (http://docs.oracle.com/javase/8/docs/api/java/util/Optional....)