3 ms·

For reusing software source I agree. The only current way around this is with the unix pipe system where you reuse software _executables_ instead of software _s

For reusing software source I agree. The only current way around this is with the unix pipe system where you reuse software _executables_ instead of software _source code_ The reason it works is because unix softwares agree to a simple contract of reading from stdin and writing to stdout, which is very limiting in terms of concurrency but unlocks a huge world of compatibility. I wonder if we will ever get software legos without the runtime bloat from forking. ps: to anyone countering with examples of languages that are reusable through modules, that doesn't count because you are locked in to a given language.

criddell 6y ago
Another current way is with COM in Windows.
meatmanek 6y ago
> I wonder if we will ever get software legos without the runtime bloat from forking. In a sense, shared object files / dynamically linked libraries meet this criteria -- they can be loaded into program memory and used by a single process. There's also flowgraph-based signal processing systems, like gnuradio, which heavily use the concept of pipes (usually a stream of numbers or a stream of vectors of numbers) but, as I understand it, don't require OS forking. (Though they do implement their own schedulers for concurrency, and for gnuradio at least, blocks are typically shipped as source so I'm not sure whether that counts as reusing executables vs. reusing source code.)