3 ms·
It could be modeled after the most largest, most successful system ever built. Standard protocols and APIs trump standard language/libraries every time. In my
by eikenberry 11y ago
It could be modeled after the most largest, most successful system ever built. Standard protocols and APIs trump standard language/libraries every time.
In my experiences, standard language/libraries always lead to complex, tightly coupled, and fragile systems. It'd probably be better to require that any one language can't make up more than say.. a third of your system, so as to avoid accidentally falling into a bad architecture.
- morgante 11y ago> It could be modeled after the most largest, most successful system ever built. What system would that be? (The internet?)
- aikah 11y ago> Standard protocols and APIs trump standard language/libraries every time. These 2 things are completely orthogonal. You can have 2 services that are totally unrelated(by definition) yet use the same libraries for these different tasks. > standard language/libraries always lead to complex, tightly coupled, and fragile systems. Don't blame "standard libraries" when you should blame developers. Do you think developers that write these fragile systems will magically write better systems with all your apis and protocols ? do you think they will magically get the proper discipline ? no they won't. They'll write bad apis and bad services, which will be even harder to refactor. I don't understand this need for "uber" complexity (no pun). It's obvious that the more languages used the more complex an architecture is. Same with micro-services which are just about shifting cost from dev to ops. I guess it will take an entire new generation of developers to understand that, the one that will have to maintain all that mess...
- eikenberry 11y ago> These 2 things are completely orthogonal. Of course they are, yet I see people mix them up all the time and standardize on language/libraries when they mean to standardize on protocols and (having) APIs. > ... just about shifting cost from dev to ops. Yes. Dev is people, Ops is process. So by shifting the cost to Ops you are shifting it to something you can automate away.