Test-driven design

Basically, when you write your program in Haskell or, if you want to go all out, even a more powerful static type system/proof checker (COQ, Agda), you are thinking in terms of proofs, which influences your design also. Are designs by proof really that different from designs by test? Interesting question.

Fundamental limitations in the various forms of static analysis means that TDD is often quicker to work with (agility) and often way more expressive. Completeness that proofs depend on when the design is being formed is also often very elusive, which is why Haskell isn't such a great rapid prototyping language while LISP is.

I can see how you don't really need unit tests when using statically typed languages, but they are still handy. TDD is not only about unit testing, it's also about integration testing and acceptance testing. In my experience, integration testing is a lot more valuable than unit testing because you may make certain assumptions about the libraries you use which are not true. With your own code that's less of a problem.

Second that. I've watched all these talks several times. It's a clear explanation on why global State is bad and how to avoid global state using dependency injection. Nowadays, I write all my stuff using manual dependency injection. I would really recommend everyone to try it out.

A rose by any other name would smell as sweet.

Being concerned about that is premature optimization (which is the root of all evil). It does not matter in any significant way vast majority of the time. If you have a really hot loop, OK, you can try removing value copies to see if that has an effect. But unless you've identified the hot code, do not prematurely optimize by avoiding parameters.

Also all the expensive values are objects, and only references to them are copied, not the objects themselves.

Not really, at least as compared to ordinary pass-by-reference. Javascript, like Java, uses references for all objects, but passes by value. So the references are passed by value, but the objects themselves are passed by reference (since they're always references).

Passing references is quick, even by value: it's just passing around pointers. Here's basically how it would look in say, Go, with pointers:

    package main

    func main() {
        var x = 10
	test(&x)
        println(x)
    }

    func test(ptr *int) {
        var y = 30
        ptr = &y
    }

And the equivalent JS:

    function main() {
        var x = 10;
        test(x);
        console.log(x);
    }

    function test(ptr) {
        var y = 30;
        ptr = y;
    }

    // depending on environment, either call main() or run on onload or DOM ready

The main difference between the two is that in JS, x and y were already pointers; in Go, x is the actual value 10, and y is the actual value 30. However in both cases the test function takes a pointer that is itself passed by value.

The programs, naturally, both print 10 and not 30. The pointer was passed by value, and modifying the value of the pointer only changes the pointer, not the referenced variable. To change the referenced variable you'd have to dereference the pointer — and since JS doesn't provide access to raw pointers, that's impossible in JS. You can, however, mutate the variable using array accessors or dot notation; for example, in Go:

    package main

    type Vertex struct {
        X, Y int
    }

    func main() {
        var z = Vertex{X: 1, Y: 2}
        println(z.X)
        test(&z)
        println(z.X)
    }

    func test(ptr *Vertex) {
        ptr.X = 10
    }

And once again the equivalent JS:

    function main() {
        var z = { X: 1, Y: 2 };
        console.log(z.X);
        test(z);
        console.log(z.X);
    }

    function test(ptr) {
        ptr.X = 10;
    }

    // depending on environment, either call main() or run on onload or DOM ready

As expected, the programs will first print 1, and then print 10.

As you can see, pass-by-value in JS is generally the same as pass-by-reference in other languages; it's all pointers under the hood.

This is what I used to think. I used to make my code pass lots of objects around in order to make it "faster", but in reality it was premature optimization, as the milliseconds lost passing a string by value is negligible compared to the dozens of developer hours lost by having less testable code.

In the examples, the parameters are value types. However, in the real world, they are usually either objects or functions.

Also, when you write code this way, you don't end up calling the constructors very often. You end up with a big up-front construction/wiring-up phase, after which your objects/functions go about their business handling user input and making server requests.

I've found that this, combined with an MVC or MVVM methodology, essentially breaks my code down into functions and data records, with the two rarely intertwining. You basically only use the "new" operator either at the start of the program's lifetime, or when you're converting data from one data type to another.

I see thanks for the replies.

So it's OK as long as you use objects and not a simple integer as a counter for instance.