3 ms·
Maybe this is part of the benefit of the whole micro-service trend? I've largely dismissed the idea until now as impractical in many cases, but this seems like
by mises 8y ago
Maybe this is part of the benefit of the whole micro-service trend? I've largely dismissed the idea until now as impractical in many cases, but this seems like a case where a team of between three and six developers could work in something like lisp (that may not scale well), expose an api, and communicate with other parts.
It seems like we really need cross-language oop for this reason. MS COM might be an example. I was reading something I clicked on yesterday when doing some reading about reference counting, and someone commented that things like MS Office (COM based) needed such things: something could be initialized in one language, passed to another, and deinitialized in a third.
- _bxg1 8y agoThis could make an interesting case for a "hybrid" Clojure/Java codebase. Write focused modules in Clojure, exposing strong-typed APIs that are then stitched together in Java.
- danielparks 8y ago> Hmm, maybe this is part of the benefit of the whole micro-service trend? I think micro-services can actually make this worse. The issue is that the early coders write macros and other tooling that makes it harder for future coders to understand. In other words, they develop their own service-specific language. With one big service, you would expect a somewhat consistent set of practices. So, one language for the entire service. With micro-services you can have a different language for each service. Worse, each language might be only slightly different. If you end up with a consistent language across all of your micro-services, then you’re back to the original problem. (I’ve experienced this effect first-hand. If I’m not disciplined I’ll do a bunch of meta programming that makes me _way_ more productive, but makes it much harder for another programmer to understand.)