Skip to content

Instantly share code, notes, and snippets.

@marick
Last active February 28, 2016 00:48
Show Gist options
  • Save marick/49ec0aceb5317089a98c to your computer and use it in GitHub Desktop.
Save marick/49ec0aceb5317089a98c to your computer and use it in GitHub Desktop.
Draft abstract for XP2016 talk

"Things are the way they are because they got that way." - Gerald Weinberg

XP, like everything else, contains traces of its history - traces that, to an outsider, seem arbitrary. The same is true of functional programming (FP). The histories of XP and FP have had little influence on each other. As a fan of both, I think that's a problem.

Possibly it's more of a problem for FP: I see XP insights being painfully and expensively rediscovered.

It's also a problem for XP. When Agile became popular, XP was eclipsed because (1) it requires a lot of discipline, and (2) it focuses on "that point in the proceedings [where] someone competent has to write some damn code" [told to me by a speaker at this conference who, at the time, wanted to remain anonymous]". As Agile became a management fad, that made XP unappealing.

FP is (arguably) at the point object-oriented programming was during XP's heydey: people with money to spend on programmers are willing to risk it on programmers programming in weird ways. IF XP can't jump on this latest bandwagon, it will miss the latest chance to change programming for the better.

Therefore (as we used to say in the patterns days): I want to bring FP and XP together. This conference is a first part of that effort: I hope to have many conversations and Open Space sessions about it.

However: my actual talk will not be about grandiose plans. In the spirit of "writing some damn code", I plan to discuss an FP-friendly programming style that spits in the face of OO wisdom: don't bother with models based on well-defined objects with behavior; instead flow dumb data (arrays and associative arrays) through a series of steps that make the dumb data even more complex (yet still just as dumb). This style eschews object-to-relational mapping for an embrace of SQL. It pays little mind to "didn't we already settle this in 1999?" certainties like "a constructor should fully construct its object". It has to survive (valid!) objections like "In 2002, we concluded that Transaction Scripts don't scale - what's different now?"

My example will contrast the Phoenix web framework (built on the FP language Elixir) to similar OO frameworks that are well-tuned to traditional XP style.

I mean this to provide a concrete example of eternal verities that are no longer true. After all, challenging such things is squarely in the XP tradition.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment