4 ms·

Definitely more interoperability to get best tool for the job and leverage ecosystems. I'm with you on that. On this... "they should focus on interoperating wi

Definitely more interoperability to get best tool for the job and leverage ecosystems. I'm with you on that. On this... "they should focus on interoperating with other languages (as in the Unix philosophy)." Maybe instead follow the OpenVMS philosophy where they standardized the calling conventions to support multi-language development. http://h41379.www4.hpe.com/doc/82final/5973/5973pro.html#intro_32 http://h41379.www4.hpe.com/doc/82final/5973/5973pro.html#int... Microsoft's CLR followed that path in the VM space. Got similarly good results. Tools like Racket and mbase do with DSL's where they share underlying LISP-like language to avoid problems with DSL's own weaknesses.

chubot 9y ago
Yup I mentioned Microsoft COM (which Mozilla's defunct XPCOM was modelled after). Shared libraries and binary interfaces, rather than C header files. Come to think of it I'd like to see a postmortem on XPCOM. Chrome uses apparently uses more of a build time tool to generate interfaces in both C++ and JavaScript.
pjmlp 9y ago
Actually on Windows we have come full circle as those CLR ideas, which were originally thought for COM Runtime, have been brought back into COM as UWP. IBM mainframes also follow the multi-language environment philosophy.