Comment by danpalmer | Hacker News Reader

Comment by danpalmer | Hacker News Reader

While this list looks solid, I think it's telling that none of the papers that immediately came to my mind were on this list.

I suspect that there are many more, and which papers are important to any one person is as varied as the disciplines we have within software engineering.

- Out of the Tar Pit 2005, a paper on Functional Reactive Programming that is an excellent read for anyone doing functional programming, UI programming, or a number of other things.

- Consistent Hashing and Random Trees: Distributed Caching Protocols for Relieving Hot Spots on the World Wide Web 1997, important read for anyone working in distributed systems or services with any sort of scale.

- Roy Fielding's dissertation 2000, to learn just how widely applicable REST principles are and how misunderstood it is as a design.

- The Part Time Parliament 1998, the original Paxos paper, important basis for anyone working with distributed systems.

- The Cathedral and the Bazaar 1997, an essay not a paper, but a good background to the open source world.

Out of the tar pit is the one I came in here to see.

I think the implications of that paper double every time I read it. Last time I walked away from that paper I decided I wanted to write a pure SQL logic evaluation system and now we're actually using it in our product to expose customization opportunities.

I almost worry what another read through might reveal. The last one was a really painful realization about wasted human capital.

Edit: I just realized the parent posted this as:

> a paper on Functional Reactive Programming

It is incredibly important to note that this is incorrect. It should be:

> a paper on Functional Relational Programming

It actually doesnt have much to do with "reactive" programming model as we know it today, and is more about managing complexity.

Paper link: http://curtclifton.net/papers/MoseleyMarks06a.pdf

The paper explicitly states that it’s about Functional Relational Programming, so that’s verifiably correct. I’m not sure if I can agree, though.

> It actually doesnt have much to do with "reactive" programming model as we know it today

What would you say is the ”reactive” model as we know it today?

If you asked me what FRP is, I’d tell you about Functional Reactive Programming. Maybe I’d point you to Conal’s writings[0] or something like Your Mouse is a Database[1]. Andre Staltz did a nice writeup on how it’s useful to think of FRP in more broader terms than the original definition would require[2]:

> it would make sense to talk about "functional reactive programming" as a paradigm or an idea where you build applications using listenable event streams (or "signals"), creating and composing them using pure functions

For me, that’s the spirit of FRP. And when I read Out of the Tarpit, that’s exactly what jumps at me. The paper seems to describe data that’s changing over time, and other data being derived from those such that when the original data changes, so does the derived one. That’s pretty much precisely Functional Reactive Programming to me, even if the words are different.

You might have another sense of the words in mind; I’d like to understand what you think, and why.

  [0]: http://conal.net/papers/push-pull-frp/  
  [1]: https://queue.acm.org/detail.cfm?id=2169076  
  [2]: https://medium.com/@andrestaltz/why-i-cannot-say-frp-but-i-just-did-d5ffaa23973b

Fielding dissertation for those interested: https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

This is probably one of the most practical ones to read. REST is so much more than "/noun/id" routes.

I'll confess that I've never been able to make heads or tails of the Fielding paper. That is, it's not that I don't think I understand what it's saying, it's that I don't relate to it; it doesn't really seem to be describing solutions to problems that have bugged me during my career.

So I'll ask you and others here: what do you think are the most important and applicable insights from that paper?

Useful heuristics. Mooted by coworker's incomprehension, poor craftsmanship, and beligerent disregard for received wisdom.

In other words, all HTTP APIs devolve into screen scrapping, which is actively thwarted by terrible libraries. So just give up any expectations and do whatever scores the most agile scrum kanban karma on your team.

I'll confess that, like the Fielding dissertation, I also can't make heads or tails of this comment.

Too cynical?

Distrust any one who claims they do understand. Because they don't.

Our study group chewed thru REST in Practice. It's very reasonable, approachable. Good advice for a lot of design choices that you'll likely run into.

Sadly, REST is like Agile. It's not possible for any two people to reach consensus on any aspect, big or small.

And just like Agile, REST doesn't matter. What ever you do will be wrong.

So just smile and play along.

Ok this I understand, and agree with, to a decent degree.

> So I'll ask you and others here: what do you think are the most important and applicable insights from that paper?

* Statelessness for horizontal scaling

* Idempotency to handle network partitions

* Request state must be inline or addressable by URL

* Hypertext As The Engine Of Application State

* Media type negotiation

* How to exploit pervasive caching

I think having these formalized in a coherent framework was very valuable, and I don't see how this couldn't help but influence your career, unless all you write are desktop applications.

This is a great list and the conclusion is very fair. I think maybe what it is is that both these concepts and various limitations and tradeoffs had already been broadly socialized by the time I came into the industry. So it's not that I don't see the paper's influence, it's more that I was never able to find anything to latch onto from the primary source which I hadn't already internalized based on its synthesis in various tools and techniques that I learned in different ways.

Honestly, just HATEOAS. If you can change your client’s behavior without actually re-deploying it, you’re doing yourself and team a huge favor. Even just backwards compatible server changes are worth it.

Is the following at all reasonable?

REST is for when you are building an API for broad “public” consumption (where “public” might mean public within your company). But many teams are actually building APIs for a very narrow audience; often just their colleague’s javascript! In that situation it’s often fine to build tailored endpoints. Furthermore, the fact that we see RPC being used by large well respected tech companies is additional backing for this view.

If you are into Out of the Tar Pit, check out M36, a relational DB written in Haskell that aims to live up to the paper:

https://github.com/agentm/project-m36/blob/master/docs/reach...

You could probably get away with SQLite too. This seems to work really well for our use cases - We integrate SQLite w/ C# and do have many functional aspects involved. C#8 is great about opt-in functional paradigms.

If you pick SQLite you can also lean on their exotic-tier test coverage and the fact that you can author application defined functions for utilization from SQL (i.e. your DSL in this usage context).

The Paxos paper...I mean it seems funny, especially so to the author's academic audience who get all the references? From the distributed systems class I took, the main takeaway was Paxos seems inaccessible mainly due to the byzantine writing style. We also read Paxos Made Simple and Paxos Made Live, and when it came time to actually implement anything, nobody used the original paper at all.

So yeah, the original paper might be fun or funny, but not the easiest for understanding the basis for consensus protocols.

I've seen that paper referenced multiple times in the vein of "Metaphors might seem nice, but never ever do what this paper did because it renders the subject matter practically inscrutable."

Came here to add Out of the Tar Pit. Here’s my clipboard: http://curtclifton.net/papers/MoseleyMarks06a.pdf

Yes! I’m (yet another) person expecting to have seen Out of the Tar Pit on the list.

Paxos paper was one of my favorite reads back in grad school. Would highly recommend

Reply on news.ycombinator.com