is lisp the answer? /linkbait

[Dustin <dustin.getz@gmail.com>]

Did anyone see the recent HN discussion[1] on John D Cook's "the
plumbing programmer" ? Cook writes:

"The plumber is often the most experienced programmer on a team. ...
software plumbing connects things together. It deals with things other
people don’t want to see or think about. And it’s crucial." and he
implies that systems integration is one of the hardest parts of
software (systems?) engineering.

A HN commenter `nadam` wrote: "Most of the enterprise developers' job
is connecting components together. I hate it. I hate modifying
existing systems and hate connecting them together. It is usually
hard, but the kind of hard which is not really fulfilling for me. It
is about fighting with accidental complexity created by other people."

`fleitz` (5800 karma) responded (summarizing): "It's not that
difficult when you work with the right tools. Most of these problems
boil down to a couple operations: map, reduce, filter ... [to and from
webservices] ... [only need four types to do this] ... Using the usual
sequence operators pretty much anything is possible with those inputs,
outputs, and transforms (pipes) and you avoid a lot of overhead making
data pipelines." [2] worth a click imo.

I responded, questioning his assertion that "most problems can be
solved with sequence operators". I would love if this was true, but i
see no evidence of "big" software systems being successfully
constructed in this fashion. "People build BIG BALLS OF MUD because
they work. In many domains, they are the only things that have been
shown to work. Indeed, they work where loftier approaches have yet to
demonstrate that they can compete." (quoting an old essay, this
actually might not be true anymore! facebook/twitter/google/amazon)
[3] I elaborate a bit in the HN thread.

Anyway, I can't help but wonder if the lisp paper we discuss tonight,
and the underlying lambda calculus, forms a proof that yes, all
computable problems may be decomposed into sequence operations, and i
wonder if that proof can be extended to convincingly conclude that
sequence-oriented decomposition of systems-integration problems is a
better* approach than big balls of mud. I recognize that many
intuitively feel this is true, but I have yet to find and understand
an argument that concludes this beyond all doubt.

[1] "the plumbing programmer" HN discussion -- http://news.ycombinator.com/item?id=3238284
[2] fleitz on data pipelines -- http://news.ycombinator.com/item?id=3240168
[3] BIG BALLS OF MUD -- http://www.laputan.org/mud/
*better -- this includes out-of-band factors like hiring, but perhaps
we can ignore out-of-band factors like perverse incentives to not care
about quality due to bill-per-hour economics.