3 ms·

How exactly do you see it done by the OS vendors ? Should they try to support every conceivable programming language out there ? Should they force every languag

How exactly do you see it done by the OS vendors ? Should they try to support every conceivable programming language out there ? Should they force every language to use a certain package format ? Until languages reach a stage where they have totally transparent interoperability - which is the ability to use a library in your language regardless of the language the library was written in - OS vendors have a monumental (impossible) task on their hands. Windows tried this with COM and ActiveX and I don't think that succeeded entirely. Things like CLR or JVM are a partial solution, but you can't expect a C++ programmer to work with the JVM or a C guy to make his hack compatible with CLR. I guess the way we have it right now is the natural "best" way. Let's hope someone somewhere gets enlightened and enlightens everyone else.

fit2rule 11y ago
I had hoped, by now, that OS vendors would have evolved a system of managing packages in a filesystem that was standardized, easily portable across operating systems, and easy to implement with a little forethought from anyone wishing to package their apps for the system or add support for the package/bundle in their language as a first-class implementation. In many ways we have this: at least in the Games world, where we can't expect the user to do package management to just play a game, we've got things like good ol' .zip files masquerading as filesystems, and thus .. our game is really a little OS with its own universe. The other end of the scale. But its really, really hard, it seems, to get everyone to agree to these kinds of standards and share things across the filesystem in a way that is easily maintainable by real people as well as automated systems. I don't truly believe all this new school of thought, either, about filesystems having to go away - to me this is just a cop-out by folks who should be taking responsibility for teaching people what a filesystem is (since we have so many of them) before we start throwing them away and replacing them with .. something .. which inevitably doesn't solve any of the filesystem problems, but does mean less code has to be maintained. Which is why I think language-people do this "NIH"'ification of the problem: nobody is enforcing any rules, so Langage-X has to have its own way of laying things out, providing common code, isolating things into common/routine layouts, and so on. It truly is, for me at least, that if your language requires package management, its broken and isn't any better than any of the other umpteen languages that preceded yours, no matter how sexy it is, and which also has "package management". The whole are is just broken and isn't fixed yet. I don't know all the answers, but I have a feeling a good start might be "build an OS, an execution environment, and a user interface using one language and one language only, and make all sub-systems of that OS utilize a standard, built-in, intelligently designed means of handling dependency graphs for user sub-modules".

fit2rule 11y ago

I had hoped, by now, that OS vendors would have evolved a system of managing packages in a filesystem that was standardized, easily portable across operating systems, and easy to implement with a little forethought from anyone wishing to package their apps for the system or add support for the package/bundle in their language as a first-class implementation. In many ways we have this: at least in the Games world, where we can't expect the user to do package management to just play a game, we've got things like good ol' .zip files masquerading as filesystems, and thus .. our game is really a little OS with its own universe. The other end of the scale. But its really, really hard, it seems, to get everyone to agree to these kinds of standards and share things across the filesystem in a way that is easily maintainable by real people as well as automated systems. I don't truly believe all this new school of thought, either, about filesystems having to go away - to me this is just a cop-out by folks who should be taking responsibility for teaching people what a filesystem is (since we have so many of them) before we start throwing them away and replacing them with .. something .. which inevitably doesn't solve any of the filesystem problems, but does mean less code has to be maintained. Which is why I think language-people do this "NIH"'ification of the problem: nobody is enforcing any rules, so Langage-X has to have its own way of laying things out, providing common code, isolating things into common/routine layouts, and so on. It truly is, for me at least, that if your language requires package management, its broken and isn't any better than any of the other umpteen languages that preceded yours, no matter how sexy it is, and which also has "package management". The whole are is just broken and isn't fixed yet. I don't know all the answers, but I have a feeling a good start might be "build an OS, an execution environment, and a user interface using one language and one language only, and make all sub-systems of that OS utilize a standard, built-in, intelligently designed means of handling dependency graphs for user sub-modules".