Comment Re:C can be the future (Score 1) 641
Having application maintaining there own libraries is more like an loosely workaround than a solution. Some libraries of one application could share information with others applications that maintain an other version of the libraries, resulting in a inflating code and complexity to support old formats or resulting on unsupported situations. The Linux way of packaging libraries require constant support from the application providers, but the advantage is a fast evolving ecosystem, small footprint, and stable operations.
I have to see an OS that can link any libraries for any language to any application. I known that the GObject introspection project dream to bring something close to that: http://helgo.net/simon/introsp... . AFAIK, Vala (a kind of C + GObject) is the most advanced experiment in that direction with automatic binding in a number of languages already functional: https://github.com/antono/vala... . But here the OS have very little to do as the hard part of the linking process is done by the GObject introspection library of each language. Please note that GObject is able to work so well precisely because the naming schema is well defined.
It's actually popular to introduce a few new languages each year and to write a lot of libraries for each languages that do almost the same job. At some point in the future, so many choices will make more problems than it solve, mainly because of the dilution of the efforts and lack of support where the community is too small. C has a big community for good reason, but C in not used for some projects for others good reasons. Some basic object programming features is probably the most obvious one, especially when observing that many C projects organize there code like objects if not directly using GObject or similar libraries. Given the today situation, I think that C could evolve in a cleaver way without making any harm.