Hacker News Reader

Comment by javascriptlol | Hacker News Reader

The problem is designing all this nonsense into the bottom layer in the first place. I've never heard a good argument as to why any of this is better than just starting with raw sockets for an app talking to a server.

Take HATEOAS for example; a completely academic waste of time. Writing a tiny bit of API documentation isn't hard. Caching is an awful thing to be designing in without knowing the specific application. Verbs are a hack bolted on to make hideous form/link driven applications work when the user reloads or moves back/forward.

View on HN

Except that when you follow all of REST, including HATEOAS, that part of the API documentation is FREE. And the caching is FREE, because its already been designed for you. Which is the whole point.

What? How can you say REST is going to give you a bunch of stuff "for free" when you haven't even seen the application. How do you know you're even going to get what you want? This is the central conceit here.

Again, downvotes but no comments. How embarrassing for HN that the crowd here can't justify their position.

How can you say (TCP|Unix|C) is going to give you a bunch of stuff "for free" when you haven't even seen the application. How do you know you're even going to get what you want?

You don't, of course, but it's usually a pretty reasonable assumption that the effort involved in implementing your own (reliable stream sockets|scheduler and memory manager|high level language compiler) will eclipse severalfold any advantage from doing so. If you don't find that the same obtains from using HTTP and hypermedia then that's your position and you're welcome to it, but don't go assuming your experience is universal.

>You don't, of course, but it's usually a pretty reasonable assumption that the effort involved in implementing your own (reliable stream sockets|scheduler and memory manager|high level language compiler) will eclipse severalfold any advantage from doing so.

Wrong. I implement network protocols for a living, and I use often use UDP because TCP is not sufficient for the purpose. So yeah, this is the problem: your conceit that your upfront design is going to be "enough" for everything.

See where I said "usually"? And where I said your experience is valid but don't assume it's universal? Right

I never said my experience was universal, nor did I imply it. So what's your point?

If "I've never heard a good argument", "a completely academic waste of time" and "why should anyone non-academic building actual systems care what it means" aren't implications that your experience is valid and others' experiences aren't, then I concede and am happy to admit that you have totally Won The Argument if it makes you feel better

In either case, I'm done here.

The fact that you think it us "usually" a valid assumption is exactly the conceit I am talking about. It's only "usually" assumed to be true because the people who have different requirements don't come to the web because it's such a limp platform.

And btw, the point I am making is not against high level constructs. Once you have sockets you can build whatever you like. The problem is HTTP is the bottom level of the web. If you had proper facilities at the bottom you could have your HTTP as a library and I can have my real-time protocols. The web constrains engineers based on some academic's rationalistic ideas about optimisation.

Still waiting for your answer.

How exactly do you expect build any automated tooling around your ecosystem of raw socket applications?

For example: indexing

You're going to need something that solves the problems HATEOAS solves when it comes to multi-service coordination.

Who actually uses or needs this kind of tooling? What exatly is "multi-service coordination" and why should anyone non-academic building actual systems care what it means? HATEOAS doesn't solve the problem anyway. What happens when a field requires fixed-point arithmetic to two places? Your tools are going to get that wrong unless you start adding types. In the end you need humans to read proper documentation and implement carefully thought out solutions. This is the XML conceit all over again.

Don't downvote, comment. Or admit to yourself that you can't respond to my criticism.

Wow, what a weak crowd. No substantive criticism, just downvotes. The HN crowd should please refrain from arguing on the Internet about design until they've learned some basic systems programming.

Please downvote this comment too. The more you downvote me without commenting, the more you confirm my superior skills in system design.

Reply on news.ycombinator.com