Hacker News Reader

Comment by ocimbote | Hacker News Reader

I feel old for I have witnessed many of these battles. But I feel that I have seen history.

There's nothing wrong in this article, in the sense that everything's correct and right. But it is an old person's battle (figuratively, no offense to the author intended, I'm that old person sometimes).

It would be like your grandparents correcting today's authors on their grammar. You may be right historically and normatively, but everyone does and says differently and, in real life, usage prevails over norms.

Same goes for REST.

View on HN

This is me, 100%. I've seen enough to realize that progress is largely each generation re-thinking and re-mixing the previous generation's problems. Sometimes the remix makes things better, but plenty of times, older generation look at what's being done and says, "wow, you really don't understand what this was originally intended for" and there's a pain in that misunderstanding and inefficiency, watching work get redone, wars being refought, and hard won triumphs being forgotten.

That goes for technology, words, political concepts, music...

The amount of people that think that insert musician here had this great original song is one of the most encountered fallacies in my daily life and online.

Not only that, people tend to compare in word and concept from the newer song to the older song! “Hey wow this song from 19xx sounds just like this new song I love”

No you fool, your new song sounds like the previous one :P. Causality matters!

Like the thousands of songs using Pachelbel's Canon.

this reminds me when I was learning programming. I was talking about it to my granddad (that pioneered a few things computer-related), and he asked me "okay great you program in C, but do you write computer programs or applications?". I'm pretty sure this nuance mattered in the mainframe-era, but 15 year-old me did not get it at all, and frankly, I'm still not sure what he meant, despite doing it for a living. But nowadays the distinction disappeared (did the two merge? did one fade?), and the REST APIs nuances did also disappear to only keep the parts that matter: those that made this model successful.

Since you have decided to expand beyond tech, I'd like to share a possibly optimistic perspective.

We are instructed to think that progress is a straight line. Without any surprise, it is not. But I like to picture it with a direction nonetheless... upwards. So as it's not a straight line, I see it as a pulse, with its ups and downs, the ups usually being mild and the lows potentially dramatically sharp.

But still somehow going up.

---

On the current and future challenges: I am mortified about what we did and are doing to the planet and horrified to witness the political tensions in Europe (not only the war, because Europe has seen Crimea, the Balkans, and war never stopped after 1945, but now, there are severe risks of expansion). Also, I do not believe in tech as a means to solve our problems, never did, never will.

So maybe my tiny optimistic pulse trending upwards is too candid and naive but at the moment, maybe blind with despair, I hold on to this idea.

Time is a flat circle.

But not really: time is an upward spiral, which just looks like a flat circle from the wrong perspective. Sometimes the distance between coils is so small as to vanish. Our job is to shove the coil up as much as we can while we are here.

In Javascript world what you describe happens every two years.

At least to me it feels like it.

Yuuup. Us fossils had a saying - "complexity kills". We learned it the HARD way.

Now the new generation of devs is re-learning the same lesson, all over again. It's all fun when you are in your 20s and the time and energy seems to be unlimited. Then you get a life, and you really start valuing a simple and working design, where everything seems under control, and your codebase is not on fire all the time.

This is why we got into distributed systems as last resort. It was a difficult solution for a difficult problem. For those that don't know, "distributed systems" is what you call "microservices" now, and 97% of the companies don't need to go anywhere near them.

The descriptivist approach has a lot of merits when it comes to language -- to no small extent, words do mean what people think they mean; this is part of what it means for words to have any meaning at all, and when entire cultures let the meaning of a word drift it's hard to figure out what ground to stand on in order to say they're wrong.

And yet... right or wrong, something substantial is lost when "literally" fades into a figurative intensifier.

Same goes for REST.

There's little immediate problem in the misappropriation of the term. The problem is how few engineers spend anything more than literally zero time actually thinking about the potential merits of the original idea (and quite possibly less). Not even talking about the people who spend time thinking about it and reject it (whatever points of contention I might raise on that front), just the sheer volume of devs who sleepwalk through API engagement or design unaware of the considerations. That's the casualty to be concerned about.

> And yet... right or wrong, something substantial is lost when "literally" fades into a figurative intensifier.

Yes, but wisdom is to avoid to conflate "lost" for "degraded".

This would be a better point if actual REST was something widely used. Then we would have lost a useful word.

But personally, I think I have never seen any actual REST that wasn't just browser-oriented HTML. So using the word for the API pattern is quite ok.

On the other hand, there's nothing fundamental about html that is encoded in the REST acronym itself. Is an http JSON API representational? Yes. Does it transfer state? Yes. If anything the cruel bit is that we use JSON over HTTP, which is "supposed to be" for hypertext.

Articles like this are good to show how fads and buzzwords in tech take on a life of their own. Hopefully there are some younger devs in this thread who can learn from it.

Us older guys have to do the opposite. As we see these things come and go, we get jaded and start to dismiss new techniques as fads. I shudder to think of how much wasted effort I put into "Enterprise JavaBeans" and "XSL Transforms". Years later, I took a look at React when it first launched, dismissed it as crap because of the mess it made in the DOM back then, and then ignored it. It took me a few years until I realized I was wrong and it was going to stick around.

You were right and wrong. Just because something is crap doesn't mean it won't stick around...

I was thinking about this the other day. One element that makes a successful senior is distinguishing fads from trends early enough, rather than just good from bad.

Trends and fads can look pretty similar in the early days, and trends often look bad early on too as they often take longer to mature than a fad. The trick is in spotting things that appear to be a bad fad, but will eventually be a good trend.

I was there, at the Tannhauser Gate....

Like you I saw the wranglings over this meaning. And today I look at the documentation and see HTTP+JSON RPC and I still FEEL "that's not REST" but whatever.

The thing that confuses me with semantic drift, is that nobody stops at any point to make a word for what the other word used to mean. It's very hard to refer, at this point, to "the thing that people meant when they said REST ~15 years ago." Can't we just come up with another jargon term for that, that isn't being squatted on?

That's usually a sign that the thing that didn't get a new word is not actually all that useful or interesting.

Highly debatable. A (too quick?) Darwinist perspective would tell us that the original ReST was not fit. And the "new" ReST (aka, JSON-RPC) is more fit.

Fit in its current ecosystem, of course.

That's exactly what I meant. The "new REST" appropriated the term because it's what's actually being used. The "old REST" didn't get a new term because it's not actually being used.

There are still theoretical discussions around "old REST", but they all have "new REST isn't REST at all" as their core point, so the lack of new terminology is deliberate there.

We use the old REST a lot and call that what you name "new REST" Json-RPC. What's so difficult about naming things what they are? I mean Devs do have some brain. That's why we are able to write cool software. But then why are some of us too stupid to get that REST thing right?

There is already a standard called JSON RPC and it is not RESTful at all. RESTful means you are using HTTP verbs to convey some information. This is a “mostly stupid” idea, but it has caught on. RESTful is an now industry buzzword. So this is what the pragmatics implement.

We may as well have a debate on what object oriented really means before implementing something, but again, the pragmatic will just create a structure that is broadly recognizable as object oriented.

Good point. My only idea would be to say it in-extenso: representational state transfer...

People do try to come up with new terms. I've seen such suggestions blog posts and comment boards.

The issue is getting everyone to agree with your new word or to even recognize the problems of semantics.

Many people also deliberately misuse the existing terms to get advantages. For example, DevOps in your title gives you a higher pay despite often being materially the same as a pure operations role or sys admin.

People often mean CRUD when they say REST.

Already done: "hypermedia"

Does it delight you?

I see in your eyes the same fear that would take the heart of me

A day may come when the courage of old web developers fails,

when we forsake our old, RESTful network architecture

and break all bonds of HATEOAS

but it is not this day

    javascript fatigue:
    longing for a hypertext
    already in hand

    // haiku FTA

It's just, why are we calling it "Rest"?

Just call it adhoc RPC with JSON over HTTP.

That's what REST has come to mean.

That's simply wrong!

REST is not a word. It's an acrynom. It's also a very technical term.

REST has come to mean non-REST the same way "literally" has come to mean "figuratively".

Reply on news.ycombinator.com