Hacker News Reader

Comment by Ygor | Hacker News Reader

For those who haven't read it yet, this paper has a lot to say about the cause of programming complexity, Out of The Tarpit:

http://web.mac.com/ben_moseley/frp/paper-v1_01.pdf

They say that the only essential complexity is the one inherent to the problem the program is trying to solve. Everything else is just here because we haven't yet found the methodology or invented the tools to battle it.

They also describe an ideal world, where all the programming is done in way of declarative programming - what you want the code to do, and not how to do it.

View on HN

this paper has a lot to say about the cause of programming complexity, Out of The Tarpit

This paper is highly regarded by some smart people, but every time I've tried to read it I've seen nothing of much value - only some obvious platitudes about complexity (including the bit about complexity being intrinsic to the problem vs. just the implementation), a lot of architectural gobbledygook (complete with boxes-and-lines diagrams), and some hand-waving about combining the functional and relational models. Has anything ever come of this? Specifically, any working systems?

Clojure.

Clojure's lispy (simple implementation, syntax), FP (reduced state), easier concurrency, agents + stm are all influenced by this paper.

That seems like a huge stretch. Lisp has nothing to do with that paper, and minimizing state and complexity could hardly be more obvious design concerns. The concurrency aspect I can't comment on, but it's not a major theme there either.

Perhaps I just don't get it, but I'm a little miffed at having tried several times to absorb the gems of wisdom in that paper and come up with nothing that isn't obvious (even the idea of functional programming over relational data is obvious) and that couldn't have been said less pretentiously in easily a tenth of the space - ironically, for a paper about minimizing complexity.

The paper was about several things:

1) accidental complexity is the source of a large number of bugs 2) implicit, unnecessary, tightly-coupled state is the cause of a significant number of bugs. 3) mostly-functional programming reduces the amount of state in 2 4) RDMS databases, with transactions and triggers, are a good way of reducing state as well

Clojure applies all of these lessons. lisp reduces accidental complexity in the language. FP reduces accidental complexity wrt to state. the STM and agents are close analogues to DB transactions and triggers.

"even the idea of functional programming over relational data is obvious". Yes, but where else has that been tried?

I posted a reply, but decided I was repeating myself. Thanks for the discussion.

So I am relatively naive when it comes to declarative programming in general and have not yet read this paper (I will after commenting here), but that said...

Don't you have to (at the very least) tell the compiler how to do things? To reuse the example from the article: when you tell your friend to get you a beer, at some point your friend has learned HOW to get you a beer. Similarly the compiler will need to know HOW to do things that you declare. Sure it will be great when we can just tell the compiler that we need this list sorted in reverse alphabetical order but at some point someone is going to have to program the sorting algorithm on the back end.

Am I way off or are we just talking about a hypothetical future when compilers are (even more) black boxed and we don't have to think about them anymore?

Declarative languages are defined by the fact that in them, you don't tell the compiler how to do things. You just describe the result you want, and it's the compilers job to get there. Yes, this makes the compiler rather hard to write.

SQL is probably the primary example. Prolog is also well-known.

For anyone who may not know, Prolog does this in a pretty interesting way. You have some declarations that make up your program, Prolog takes these and then uses them to conduct a logical proof (like in discrete math). You negate the premise (proof by contradiction), and then try to show that this will cause a contradiction (line 5 says Bob is Human, but line 42 says Bob is not Human). If you can find such a contradiction, your premise was true.

It does this by using backtracking, which is really interesting in itself if you're not familiar with it.

Also fascinating is the amazing and innovative virtual machine that drives Prolog: the Warren Abstract Machine.

See: http://wambook.sourceforge.net/

Great paper. I'm familiar with it, and I think it's one of the initiatives out there pointing in the right direction. Same as Prolog and SQL. But we still have to work a long way in that direction for it to pay off nicely in our day to day!

Reply on news.ycombinator.com