lyinsteve

The Swift optimizer has matured dramatically since 2017, to the point where I think this benchmark would almost certainly not result in a 3x power usage/4x slowdown compared to C.

On the current benchmark game, many of the purely algorithmic benchmarks are close to C performance, but many of these benchmarks seem to be stale and haven't been touched in quite a while. It would be nice if someone went through and rewrote these using current idiomatic Swift (where many of the "use unsafe bits for speed" tricks are unnecessary) and see how it really stacks up.

I don’t know much about rust specifically, but the overflow traps happen in debug (i.e. -O0) builds, and are not emitted when optimizations are enabled.

LLVM’s constant folding and canonicalization passes will convert (x * 2) / 2 from

%0 = mul i64 %x, i64 2

%1 = div i64 %0, i64 2

to

%0 = shl i64 %x, i64 1

%1 = shr i64 %0, i64 1

Which constant folding will reduce to just %x.

There are tons of amazingly-smart people working on Swift at Apple right now

-swift-version 3 really just turns on some different paths through the parser and type checker to allow previously-valid Swift 3 code to survive to code generation time.

They're both compatible

I have the strange feeling this will really only be used to enforce the copyrights of large music and movie industry corporations and will not be effective at protecting the IP of independent creators.

This should be much higher. Thanks!

The author completely missed the point of named parameters. How am I supposed to know that the string argument of "make_window" is the title?

Why did I just implement this in Swift? https://github.com/harlanhaskins/Base65536.swift

Apple uses XMPP internally as a way to securely communicate.

Doesn't really change much; just thought that'd be an interesting thing to throw out.

I'm a Computer Science House member -- Drink is still a staple of our organization! Where else can you get Jolt on campus?

Also we've since made an awesome web app and iOS app for dropping drinks.

Surprisingly salient and cogent points for an article that's so hostile and willfully ignorant.

The author is correct about when to use both, and I'm glad he doesn't discount structs entirely like I've seen from some OOP strongholds.

"The way they write functional programs for decidedly non-functional problems is through a trick called a monad, which I will not explain and nobody understands anyway,"

Maybe you'd be less hostile if you actually took the time to learn about generic abstractions and how they can greatly simplify a codebase.

Hint: Optional is a monad, and you can use it as such.

>The move fast and break things approach

Sounds like something I want no part in.

LLVM has a GitHub mirror, too.

https://github.com/llvm-mirror/llvm

Why no mention of GCD here? GCD is very, very good at synchronizing access to shared resources.

The most Cocoa-compatible way of handling background execution of expensive procedures is always going to be best executed, quickest, using Grand Central Dispatch.

For example:

    @interface Foo ()
    @property (nonatomic) dispatch_queue_t backgroundQueue;
    @end
    
    @implementation Foo

    - (BOOL) veryExpensiveMethod:(id)arg completion:(void (^)())completion {
        dispatch_async(self.backgroundQueue, ^{
            if (_counter++ > N) {
                _counter--;
                return NO;
            }
            // Critical section
            _counter--;
            return YES;
            dispatch_async(dispatch_get_main_queue(), completion);
        };

That will ensure every call to -veryExpensiveMethod is run in sequence, and won't require waiting on your end.

These problems have been solved, better.

>50. Give Steve Jobs as much authority as he wants in new product development.

    let x: String = {
       if 3 == 4 {
          return "Hello"
       } else {
          return "Goodbye"
       }
    }()

Although in this case, I'd just use ternary.

    let x = (3 == 4) ? "Hello" : "Goodbye"

This looks really amazing. Probably the most simple implementation of FRP I've ever seen, nonetheless in Swift.

Seems like performance always works in Swift's favor when the compiler is able to reason about the types (e.g. no AnyObject nonsense, banishing the objc dynamic behavior).

Interesting to see Generics performing so poorly, though.

Please don't use hamburger menus on iOS. http://blog.manbolo.com/2014/06/30/apple-on-hamburger-menus

Did he file a bug report?

Great job!

A few suggestions:

1) You may have better results with your pixel art if you change the filteringMode of your SKTextures to SKTextureFilteringMode.NearestNeighbor instead of .Linear.

2) You might want to store SKTextures in your imageDict instead of full SKSpriteNodes. It seems you aren't reusing those nodes, just the textures.

3) Maybe use a plist file to store the level data instead of hard-coded array constants? It's a little more flexible once you abstract the data outside of your source code.

They were a launch partner when Apple announced Apple Pay. They most likely had advanced knowledge and have been working on integration for a long time.

Not to mention third-party keyboards are not allowed in password fields. I guess that's unfortunate for anyone with non-standard unicode in their passwords, though.

I'm personally fond of filling an error buffer, but a bit more explicitly than just an int.

    typedef struct APIError {
        int code;
        char *description;
    };

    /**
     * Returns NULL and fills the error parameter if creation was unsuccessful.
     */
    Something APICreateSomething(bool param1, int param2, APIError *error);

So common execution would be:

    APIError error;
    Something something = APICreateSomething(true, 3, &error);

    if (error) {
       // handle error...
    }

And if the user passed in NULL for the error parameter, then that's their problem, and they won't get error information.

All that's saying is that they can use whatever mechanism is available to unlock the device. In an enterprise environment, the supervisor has the credentials to unlock the device.

> "Oh, and… there’s a bypass switch for pairing anyway"

Nice conjecture. Please show us actual evidence of that.

Swift is built with Objective-C interoperability in mind. All of the Objective-C Foundation classes are available in Swift, and they've done their best to mitigate the differences in software design.

However, learning Swift without first learning how the underlying Objective-C libraries work, the design patterns, the available functions, Swift-Objective-C-Interop is going to be very difficult.

I'd recommend learning Swift and Objective-C at the same time. If you learn how to do something in Swift, learn how to do it in Objective-C. Objective-C isn't going anywhere, any time soon.

>Having grown in power since the original Crisis, even the other three kingdoms united were not enough of a deterrent to forestall attack

>forestall attack

>Forstall

Jobs saw it coming.

>The Go language designers noticed that people were relying on the fact that keys were normally stored in the order they were added in, so they randomized the order in which the keys are iterated over.

Um, I'm just a first-year CS student here, but isn't that a core part of how hash tables work?

They can so efficiently store and lookup data because they essentially store contents in a list with the indices as the hashes of the content.

As such, one can never reliably predict the order of the keys in a hash table, by design. That's not a feature of Go.

Sublime text is really nice, but I can't bring myself to ditching vim for Sublime, even with a nice, keyboard-shortcutted workflow.

Vim is just way too fast for me to leave.

Also because iOS development is, in my subjective, biased opinion, much less of a pain than Android development.