Re: is lisp the answer? /linkbait

[Bonnie Aumann <bonnie@bonniea.com>]

Interestingly, when I first read this I interpreted it as design pattern that has our cognitive limitations at its root. Sort of an in-group out-group preservation of resources problem.Â

Small teams of programmers can deal with the most basic integration point - checking in and merging code - by writing small amounts of well-tested code and merging frequently. Once the value is demonstrated, they see investments in unit tests and continuous integration servers as essentially self-interested because hey, bad merges suck. Go one step further and you get devops writing self-provisioning and deploying scripts.Â

At some point the application gets too big for your small team. Or you want to work with someone else's data. Since both sides have only so many resources, they do what makes their own process as painless as possible - for them. As a team, you're always balancing quality/time/features and what's acceptable technical debt to you may well be a huge pain to someone else. As Dustin aptly quoted "[systems integration]Âis about fighting with accidental complexity created by other people." Doubly so when there's no single, shared communication method that fits all cases like Mat pointed out.Â

So while I'm not at all qualified to judge whether map-filter-reduce/decomposable systems are The Answer, I'm inclined to be dubious ;)Â

Sorry for the lack of references!

--
twitter: @bonniea
site:Âhttp://bonniea.com

On Wed, Nov 16, 2011 at 11:41 PM, Dan Mead <d.w.mead@gmail.com> wrote:

I think the problem you guys are talking about is addressed by this project, also run by a major java and Haskell language contributor (phillip wadler)


http://groups.inf.ed.ac.uk/links/


basically, you can write a web app in a single program that is compiled into the nessicary _javascript_,html,backend, etc etc

it's very much a proof of concept, but hopefully stuff like this becomes the norm eventually.

it certainly wouldn't remove the factory-ish type of work completely, but maybe a unified language like that for Web apps would at least make it less time consuming

Dan

On Wed, Nov 16, 2011 at 1:38 PM, Mat Schaffer <mat@schaffer.me> wrote:

On Wed, Nov 16, 2011 at 10:14 AM, Dustin Getz <dustin.getz@gmail.com> wrote:

systems integration is hard because the underlying systems aren't designed to be composable, or at least in big systems it never turns out that way. i wonder if systems never turn out composable because they are implemented using patterns that aren't composable (by people who don't undertand referential transparency, or even know what it is). and if all systems were implemented, from the smallest, most tactical level, all the way up, using composable patterns -- referentially transparent patterns -- the natural outcome is composable software components. which would mean "finding the right glue" isn't hard anymore.

I'll admit that I don't know whatÂreferential transparency means. And apologies if this is OT, but here are my thoughts on glue and integration.

As far as I've seen the lack ofÂcomposableÂsystems is because the means of composing then isn't consistent. Single-broker message queues, ÃMQ, protobufs, messagepack, json, http, html. Nothing fits every situation or something does maybe it's not approachable enough for people to choose it. If everything were in a single Lisp runtime you'd still have this problem (afaik) when you start scaling out horizontally. Even Erlang's IPC breaks down when the number of machines grows too large.

I find the "glue" tends to largely center on making disparate systems talk to each other. Until we can find a good common transport andÂmarshalingÂsystem that covers most cases, the glue will likely continue.

-Mat