But, of course, the "if we don't like Node.JS, we just don't understand the true way(tm) of using it" card.
Such narratives usually get louder and louder, until they flip and all the former supporters of X suddenly proclaim "I can't keep quiet anymore, I must speak against X".
I've seen this too many times.
I like Node.JS, it's a good thing it exists, but no technology is perfect and we should be capable of honestly discussing the strengths and weaknesses of a given technology.
No comment on typing, if you can't bother to do basic research over whether what you say makes sense in real projects.
I'll just say that in 2014 proclaiming that your multicore application architecture is spawn() and fork() can only induce laughter in the presence of proven distributed computing algorithms that don't require every developer to use a roll-your-own message passing library and protocols.
Fieldman's work doesn't exist in vacuum. He talks about HTTP, and HTTP has the verbs it has. It's hard enough to find consistent behavior in HTTP servers and proxies with "PUT" and "DELETE" let alone anything else. But even ignoring that, the verbs the spec talks about are limited. And that's a big problem.
As for RPC, essentially any communication between machines is a RPC. It's message passing ("call") and if the message arrives on the other end it's processed by a message handler ("procedure").
No server can just reach into another server's RAM and get or modify a resource directly. The interaction happens entirely by the will of the message receiver, and in exactly the way the receiver wants (not the sender).
So if we'll be building everything on an appropriate abstraction, it better match what really happens (messages, message handlers) and not some wishful thinking abstraction layered on top (resources, resource modification).
RPC is not REST's problem. The problem is the limited commands (PUT, POST, DELETE) and the single possible query type (GET) that we need to work with.
When a payment gateway has to represent a simple "process payment" command with a series of bogus abstractions like a "POST /payment/transaction/new", you know REST is the wrong tool for the job.
None of them are dead. As for why, long story short, because HackerNews' code is really poorly written. Gateway errors, horrendous response times, bogus limits and false positives. My usage patterns are likely not typical, but this is hardly an excuse for such a poor UX.
For example, I couldn't even respond right now through mantrax5...
Next time I'll just take the alternative and instead of making more accounts, I'll just stop visiting the site completely.
Most of those principles can be bent to mean anything out of context. This is why citing principles alone can never be an argument for or against a certain design decision for a specific project situation when it comes down to it.
When you can't stop citing Uncle Bob slogans or Martin Fowler anti-pattern definitions, you're exercising Mantra-Driven Design. You've given up thinking, and you're making project decisions for religious reasons, citing what various deities said, and interpreting it like the Devil interprets the Bible.
The solution to OP-s problems:
1. Define a clear, minimal interface between "Stan's" classes and your own classes.
2. Communicate via that interface (when I say "interface", it doesn't have to be one interface type, BTW), and only via that interface.
3. Let everyone code their classes as they wish, and let the results speak:
- If either developer produces significantly more defects and issues over time than the other, have the decency and courage to learn from your team-mate. Because the interface is defined (see points 1, 2) it means you can refactor all code that isn't part of the interface. You can add classes, remove classes and you can assign from zero to infinite responsibilities to your classes, do whatever you want.
- If not, then this is one more instance of a valuable lesson: there's more than one wrong way to do things, but there's also more than one right way to do things. Maybe both developers have a good approach, they're arguing over B.S.
Such narratives usually get louder and louder, until they flip and all the former supporters of X suddenly proclaim "I can't keep quiet anymore, I must speak against X".
I've seen this too many times.
I like Node.JS, it's a good thing it exists, but no technology is perfect and we should be capable of honestly discussing the strengths and weaknesses of a given technology.
No comment on typing, if you can't bother to do basic research over whether what you say makes sense in real projects.
I'll just say that in 2014 proclaiming that your multicore application architecture is spawn() and fork() can only induce laughter in the presence of proven distributed computing algorithms that don't require every developer to use a roll-your-own message passing library and protocols.