David Tchepak dtchepak

https://twitter.com/puffnfresh/status/307868744401694720

No, still not interesting. :) If your test says code must be O(n), and there is no code, then the test fails (the code does not have that property). If the first test written is "must be O(n)", you could pass this with id.

AFAICT TDD is not about specification* or correctness. It is a mental tool (in the same way a TODO list is a mental tool) for aiding focus, encouraging small steps (divide and conquer) and making steady, incremental progress. Identify a difficiency in what you are currently working on, come up with a test that describes this difficiency (RED), implement just enough to pass that test (GREEN), then see if you can express that in a cleaner way while keeping the test passing (REFACTOR).

This doesn't have to be code-specific, you could use this approach to write a book**. Tests could be tasks on a TODO list, a type signature, an automated unit test, acceptance tests, property test, or whatever. It is just a tool to aid thinking th

	public class STRunner {
	private class STToken { }
	public A RunST<A>(ISTScope<A> scope) {
	return scope.Get<STToken>().UnsafeRun(new STToken());
	}
	}

	public interface ISTScope<A> {
	ST<S, A> Get<S>();
	}

	using System;

	namespace Workshop.Terminal
	{
	// Meh, close enough
	public sealed class Unit { }

	public sealed class IO<T>
	{
	private readonly Func<T> ioAction;

	/* Referential Transparency (RT), from http://dl.dropbox.com/u/7810909/docs/what-does-fp-mean/index.html

	Program 1:
	X x = function(args);
	R r1 = arbitrary(x);
	R r2 = arbitrary(x);

	Program 2:
	R r1 = arbitrary(function(args));
	R r2 = arbitrary(function(args));

	import Control.Monad
	import Data.Maybe

	takeUntilBlank :: [Maybe a] -> [a]
	--1)
	--takeUntilBlank [] = []
	--takeUntilBlank (Nothing:_) = []
	--takeUntilBlank (x:xs) = maybe [] (\a -> a:takeUntilBlank xs) x
	--
	--2)

	sum = function(xs) {
	var total = 0;
	for (var i=0; i<xs.length; i++) {
	total += xs[i];
	}
	return total;
	}

	********************

	[Test]
	public void Check_across_different_types() {
	var a = Substitute.For<IFoo>();
	var b = Substitute.For<IBaz>();
	var c = Substitute.For<IFoo>();

	a.Zap();
	c.Zap();
	b.Gloop(1);
	a.Bar();

	exports.OptionMonad = {
	bind: function(f, m) {
	if (m.isEmpty) return m;
	else return f(m.value);
	},
	unit: function(x) { return new exports.Option(x); },
	}

	exports.Option = (function() {
	return function(x) {


	static Func<A,C> SomeFunction<A,B,C>(Func<B,C> f, Func<A,B> g) {
	throw new NotImplementedException();
	}

	"Is Clojure code hard to understand? Imagine if every time you read Java source code and encountered syntax elements like if statements, for loops, and anonymous classes, you had to pause and puzzle over what they mean. There are certain things that must be obvious to a person who wants to be a productive Java developer. Likewise there are parts of Clojure syntax that must be obvious for one to efficiently read and understand code. Examples include being comfortable with the use of let, apply, map, filter, reduce and anonymous functions ..."

	-- R. Mark Volkmann, http://java.ociweb.com/mark/clojure/article.html