My Swift Dilemma

As for the promised runtime performance improvements they have yet to surface and worse: the language is still plagued by extremely uneven performance, even for optimized builds. I could go on at great length citing issues that will be hard to fix within the next year or so. Unfortunately. This is what my fairly hard won (15k loc of Swift code) experience with the language has revealed so far.

I can honestly say I really wish you were right.

It was a nightmare getting it all building right (generic methods on generic classes took me a bit of time to sort out) but I think it works well now.

As for performance noting the amount of Swift you've done (and your activity on the DevForums) I expect you know all this but I've done quite a bit on speeding someone else's code up. There are certainly plenty of ways to accidentally slow down code:

Summary of the optimisations taking someone's project from 10fps to about 1500. http://blog.human-friendly.com/swift-optimisation-number-ios...

Presentation on how to make Swift go fast: http://blog.human-friendly.com/london-swift-presentation-swi...

> I think this is somewhat incorrect. You should never just be type-casting your inputs. (In fact, I think it should ideally be impossible to do so without the compiler generating really big flashing warnings saying "THIS IS DANGEROUS!"). The static verification here will prevent you from doing silly things, and should ideally force you to do input validation at the location of input, instead of blindly casting things to the type it needs.

I did not say anything about type-casting inputs. I said coercing values into a given type. The naïve approach can be to type-cast, the other way is to write the code for the coercion process.

    // some collection we are holding the values in for some reason
    NSMutableArray *inputValues = [[NSMutableArray alloc] init];

    NSString *someInputValue = // probably read from user input or a file
    NSInteger value = [someInputValue integerValue];

    BOOL validInput = YES;
    if (value == 0) { // we need to check that there really is a value of 0...
        NSString *trimmed = [someInputValue stringByTrimmingCharactersInSet:NSCharacterSet.whitespaceCharacterSet];
        NSString *trimmed0 = [trimmed stringByTrimmingCharactersInSet:[NSCharacterSet characterSetWithCharactersInString:@"0"]];
        if (trimmed0.length != 0) {
            // oops, actually had an error... handle it
            validInput = NO;
        }
    }
    
    if (validInput) {
        [inputValues addObject:@(value)];
    }

Also, the compiler doesn't help me get things correct... the only thing it would have helped me do is make sure I put an integer into the array, not that I had the right values in the array. Had I not known that `integerValue` returns `0` in its error cases, I would have not known that I need to write some additional code to verify the string value was indeed a zero.

And generics only helps you when you have collections of identical types. Storing arrays of plist entries, for instance, requires you to revert back to `AnyObject` (or similar).

Generics can be helpful, if it's done well. However, even in .NET's generic system, with all the limitations and constraints it put in, there are many times where it still gets in the way.

I'm tired of fighting with my tools just to get the job done. Currently, Swift makes me fight a heck of a lot more then I want to or need to just to make the compiler happy. The end code I write is the same both ways, but the Swift code has a lot more annotations and is a lot less flexible.

> I'm aware that addition is a toy example, but suppose we want to test our implementation: > Except for very simple verification, to exclude obviously broken implementations, I'd rule out testing specific values such as 3+4=7. And, like you said, performing an exhaustive exploration of all values is out of the question. > So I'd try property testing instead. Relevant properties in this case are associativity, commutativity, etc. > As an example, I'd try writing properties such as: > for all X, Y: add(X, Y) = add(Y, X)

These properties can also be satisfied by implementations of add() that: - return a constant value - return the smallest number of (x, y) - return the largest number of (x, y)

The cases you threw out as an "obviously broken implementation" are required to actually validate that functionality of the method. The functionality of the method is also one of the properties of the method.

You can write it in a more generic way than simply: assert(7, add(3, 4)). However, those tests are _also_ required. Without them, you never actually test that the `add()` function does what it's supposed to: add two numbers together.

Regardless of type system, you also have to worry about underflows and overflows - another property of the functionality of the method.

> You are right, without additional information property testing would be less useful. Which is yet another reason to favor static typing in my opinion.

Static typing doesn't help you constrain sets of inputs; it may not be valid that your method accepts all ranges of integers. You could have a method `addbase2(int x, int y)` that is to be used only when x and y are powers of two because of an optimization you perform in that method. Static typing doesn't help you generate the correct input set for x and y.

The only thing that static typing provides, in regards to test cases, is this:

    def add(x, y)
      assert x is int
      assert y in int

      return x + y

    // test cases
    assertIsThrown(add("foo", "bar"))

Regardless, the point of the article was not about static typing being bad. There is value it. However, there is also value in not being so rigid in your type system that things don't work well.

    add((short)0, (long)1)   // compiler error if you have an extremely rigid type system

Here you'll find references from big names (Peter Norvig, Joshua Bloch) discussing limitations of TDD as a design process: http://gigamonkeys.wordpress.com/2009/10/05/coders-unit-test... (read it, it's more balanced than you'd think).

Here are some interesting comments from the above:

- Bloch: tests are inadequate as documentation.

- Norvig: I like TDD but it's inadequate to discover unknown algorithms.

(The infamous Sudoku Solver debacle is a particularly painful example of Norvig's claim, and in particular I think Ron Jeffries' attempt at doing TDD was embarrassing. Like the blog says, if I were a TDD proponent, "I'd be pretty strongly tempted to throw Jeffries under the bus")

Very few if any of the people mentioned outright dismiss TDD, but they do point out its limitations, which to me are mostly about TDD as a design process.

If we go back to TDD as testing, my initial objections apply: it's useful, but it's not enough. More advanced and formal tools, and static typing, are of great help here.

Even if you disagree with everything else, you must at least agree with this: computers are about automation. Automating as much as we can, including testing, is a good thing. Writing tests is itself something that can -- in some areas -- be automated, in which case it should be preferred over hand-writing those tests.