javascriptlol

Unfortunately, there will be no UDP protocols. So we're not quite back to where we were in 1970 yet.

You presuppose several things: 1) that "analytical" thinking (whatever that even means) is superior to "emotional" thinking, and 2) that benefits can be boiled down to economic nonsense (e.g. "money", "happiness").

I dispute the existence of "resources" in the abstract sense people are trying to achieve with respect to REST. The web is just a collection of stuff with ephemeral links to go from thing to thing. Obviously, these could be called "resources", but not in the coherent sense implied by REST.

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.

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

Unfortunately, during our circle back to the 1970's we lost UDP, which is essential for real time protocols.

The web was never a set of "addressable, reusable resources".

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.

>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.

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

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.

Still waiting for your answer.

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

Can't see why you're being downvoted here. I think it's a reptilian defensive response from the REST academics.

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.

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.

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

If I want to raise my blood pressure into the 180's all I have to do is open a thread about web design "principles".

He has the perfect anti-example for HATEOAS right in there: financial transactions. You would never in 1 million years want to discover the API for such a thing by experimentation, because there are specific precision requirements.

Every time someone tries to explain the benefits of this nonsense to me it's either 1) something you could already do with sockets 20+ years ago, or 2) a poorly motivated academic idea that doesn't get me closer to implementing a correct system with good documentation.

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.

I'm not saying the govt should regulate Zynga. I'm pointing out that they do regulate slot machines. That's because people know slot machines can be bad for people, and are generally a pointless waste of time and money that feel good in the short term. Clubs and pubs that operate those machines and know damn well that people misuse them resist these regulations to the last. The same attitude toward voluntarily stopping these things is being displayed here. And the TV thing was an accidental misstatement. I think the same thing is true to some degree or another of serialised TV and most MMO's. Serialised TV is all about making you want to see the next episode. MMO's are all about rewarding high play times rather than skill.

>We're still in the infancy here in learning how to harness mobile devices to make better products.

What this unpacks to: Let's make some money before people realise what's up.

If pg is sitting off in the background trying to convince people to click buttons with zero thought being exercised, then yes, Hacker News should be voluntarily time-limited. Until then, it is an apples-and-oranges comparison. Video games and TV have always been pretty pointless, but at least you were exercising some skill. These games are no better than slot machines, which are regulated in many places for good reasons.

So why don't you put a strict limit/spend limit on the game? Because you don't care about the ethics, except insofar as it sticks to you.

People have the right to decide whether they smoke cigarettes, too. But most people can see it's a harmful addiction and that it is plain unethical to profit from it. And yeah, I think World of Warcraft falls into the same category. Why don't they put hard play-time limits on the game? Because they don't care if you waste your life in front of their game.

This is the problem with large businesses; they can always say the supposed positives to the majority outweigh the real harms they are doing to a minority. Don't you think inducing people to click on stuff over and over with absolutely no skill is unethical? Comparing "social games" to other harmless diversions is like comparing a culture of drinking a few beers at the end of the week with a culture of encouraging people to drink as much as they want.

So, because sometimes you get it wrong you should go through life without considering the consequences of your actions? I don't think that's a good way to approach ethics. A better idea would be to learn from these incidents, speak out against your old employers and be more prudent with future employers.

It's a disturbing feature of modernism that people are hyper-focused on "evidence". Most studies are pretty inconclusive anyway. People know, in their heart of hearts that these games are pointless and exploitative. We don't know what the effects are. In a better culture we would tailor our arguments in accordance to our ethics, not look for excuses to keep profiting off something questionable.

It's pretty obvious that these games are just elaborate slot machines. Like slot machines, the companies involved simply don't care about the ethical issues. And you're apparently happy to profit off these activities until the evidence sticks to you. Just like the cigarette companies have always been eager to profit off a questionable business due to "lack of evidence". For shame.

>But now that I think about it, I realize why people have a hard time understanding REST. It's not a "design" constraint any more than OOP is. It's an implementation constraint.

Your attempt to enforce some dichotomy between design and implementation is hopelessly misguided.

>That's why REST emphasizes caching, stateless communication, the appropriate use of status codes, and the appropriate use of VERBs (idempotent vs non).

These don't solve the major problems. If I want caching I can trivially implement it myself. It's a useless thing to implement at the architecture level.

Similarly for idempotency etc. It's all a huge academic wank. An appropriately designed protocol will solve all these problems without the constraints.

>I wouldn't write an OS kernel in Ruby either.

What smug yet clueless response. You're begging the question.

I'm frankly bored of talking to someone who knows nothing about protocol design, but defends HTTP as a "proven" technology. It clearly isn't, it fails on many levels, and the whole web stack is completely fucked. Good day.

The first run will be intolerably slow. Caching will not be sufficient.