Gimme Swift

As a computer programmer, I live in a familiar cycle: Write some code, then run it repeatedly to work out all the kinks. There is a moment when you hit “run” for the first time, already anticipating what the errors might be, thinking about next steps when the error inevitably presents itself.

It’s been weird writing server-side Swift. I do my hacking, adding a feature or refactoring or whatever, I make the compiler happy, then it’s time to get to the nitty-gritty. I roll up my sleeves, start the program… and it works. Just like that. I run the tests against the other systems. It works.

It’s like you’re all ready for a fight and the other guy doesn’t show up. NOW what are you going to do?

Swift can be annoying with how hard-assed it is about certain things, but that picky compiler that sometimes forces long-winded syntax is like that really picky English teacher who you realize after the fact gave you a command of words you didn’t have before. If you have a null pointer in Swift, you went out of your way to create it.

Programming languages exist for the convenience of humans, not machines. So if you can make a language that makes it harder for humans to make a mistake, why wouldn’t you?

Man I enjoy writing code in Swift. Of the four languages I use regularly, Swift is hands-down the one I’m most productive with, even though I’ve been using the others for far longer. And just today I remembered that functions could return tuples, and I was like, “Damn!” all over again, thinking how I can shrink my interfaces.

That and a performance profile comparable to C (each is better for certain sorts of operations), and you have a language with some mojo. This ain’t JavaScript, homey.

Most of my days are consumed writing code in other languages (at least for now), and what strikes me every day is that the mistakes I make would not have been possible in Swift. Think of that!

3

3 thoughts on “Gimme Swift

  1. I have a question. I’ve started doing some command-line scripts using Swift. In them, the help() function always exits the script.

    When I use guard, I have to include an exit() that will never be reached. Or at least, I think I do. Is there a way to tell Swift that a function is an exiting function, putting it on the list of allowed guard exits?

    Here’s where we find out if your comments supports the PRE statement…

    #!/usr/bin/swift
    import AppKit

    func help() {
    print(“You can order the Frog.”)
    exit(0)
    }

    var soundName = CommandLine.arguments[1]
    soundName = soundName.capitalized
    guard let sound = NSSound(named: NSSound.Name(soundName)) else {
    print(“With a financial statement like this you cannot order the ” + soundName + “.”)
    help()
    exit(0) //this line is never reached
    }
    sound.play()
    while sound.currentTime < sound.duration {
    usleep(100000)
    }
    sound.stop()

    • Like you, I’m a bit surprised that the compiler doesn’t recognize that your help function always exits. Structurally I would prefer to see the exit in the guard statement instead of in the function, but I’m sure there are times when your flow makes more sense.

      Maybe you should submit a bug report.

      • Thanks. I considered separating out the exit(), but most calls to help aren’t in a guard, they’re in a long list of switch cases, looking at each command-line argument, and calling help, and exiting, if an argument doesn’t make sense. In every case, help would be followed by an exit.

        Maybe this would be a simple way of learning to submit a bug report.

Leave a Reply

Your email address will not be published.