4 ms·

As someone born in the 21st century, I've always found this to be a weird distinction. Why can't we unify them in just one concept?

• pjmlp 4y ago
  Because they cover different scenarios. If you want the previous one concept, you can get it via static linking alongside OS IPC. However it requires more OS resources and is complexer to program. Now every shared functionality has to do a shared memory or pipe configuration dance, to expose their functionality.
• astrobe_ 4y ago
  Maybe it looks weird now because libraries were collections of subroutines, then have evolved as sub-programs (some spawn their own threads to do their job), and then eventually got so big that they became the main program in which you plug your own moving parts: frameworks. Moreover, it is interesting to note that in the same time, the opposite trend exists: some libraries used to be the "meat" of a program, but as connecting two programs in flexible ways is not always easy, that core was extracted and made available directly to other programs. Well-known examples are libCurl and zlib.
  • eru 4y ago
    I think grep was an example of the latter, too?
    • astrobe_ 4y ago
      Definitely, and your example makes me understand the point of view of OP better: why wouldn't programs also be loadable libraries?
      • classichasclass 4y ago
        TempleOS works like that. You can just call functions directly in any program. http://www.codersnotes.com/notes/a-constructive-look-at-templeos/ http://www.codersnotes.com/notes/a-constructive-look-at-temp...
• jayd16 4y ago
  If I import a library, I probably don't want to spend the overhead importing a gui I won't be using. Code stripping could handle it but that assumes you know how to strip the libraries safely. Another way to look at it is other needs outstrip the mild convenience of packaging library and exe code together.
  • throwaway09223 4y ago
    What GUI? I think you're misunderstanding. No one is proposing changing how things link. The concept here is that executables and objects are the same structures and there's no reason why we shouldn't be able to link to a routine found in /bin/ls as we would link to a routine found in libm.so. This has nothing to do with "packaging library and exe code together."
    • jayd16 4y ago
      I suppose I extrapolated a bit too far but I don't really see the point if not to package them together. If you wanted to link against an executable such that it was safe to do so, why not go further and pull apart a library for that executable and others anyway?
• mike_hock 4y ago
  Doesn't TFA demonstrate that they are, in fact, the same concept?
• layer8 4y ago
  With executables you know they have one and only one entry point that conforms to the OS’s process execution conventions, which is a useful property to have be immediately apparent. Libraries can be seen as either a superset (any number of such entry points, most often zero) or as the separate category of binaries having no such entry point. In the world of client-side rendering, one could ask a somewhat similar question of why HTML and JS files are a different thing, and why you can’t just load a JS file to run your SPA in a browser.
  • charcircuit 4y ago
    You could just error out if you tried to run something without a main function.
• arinlen 4y ago
  > As someone born in the 21st century, I've always found this to be a weird distinction. Why? I mean, what use do you see in executing a shared library? It sounds like adding complicated and unnecessary usecases.
  • eterps 4y ago
    It's the other way around that can be suboptimal. If some application wants to integrate git it could execute in a subshell (which is frowned upon for good reasons) or use libgit instead. This works great in the case of git, but for all other useful stuff that doesnt have its own lib that provides that basic functionality you're out of luck.
    • arinlen 4y ago
      > It's the other way around that can be suboptimal. If some application wants to integrate git it could execute in a subshell (which is frowned upon for good reasons) or use libgit instead. What's wrong with invoking an executable or using libgit? It seems you're totally missing the whole point. The problem was never that you could not consume libraries from an executable. The actual problem is that you're somehow expecting to consume a third-party package in a way that the project maintainers do not support, let alone maintain. Adding a build flag that supports a convoluted and arguably useless usecases of linking with symbols shipped in third-party executables change nothing.