The interesting aspect here is how sharing happens. What are the artifacts you produce, how are they published, located, acquired, integrated etc? In a shared-first approach this is built-in to the system. Like a persistent world multiplayer game, you create stuff in a shared virtual word that easily visible to others, and available for reuse and remixing. In an individual-first, this not a big concern because existing sharing methods may be deemed sufficient and are outside the system itself (copy files around, push to git etc.) I think the single shared world idea affects fundamental design decisions around composition methods. For instance, copying code files that need to be compiled into libraries does not seem the same as linking to a web page. The web is halfway there. It's a shared world where any published page has a URL and can be linked to. However the links are unstable and only jump links are available (no other forms of composition) and local development is outside the system. Projects like Unison and the Object Network are attempting to get there, it seems. Both have the notion of a 'global id' to locate an element. Fluid is similar too, I think? An earlier related idea from Joe Armstrong (Why do we need modules at all?) is

I am thinking more and more that if would be nice to have *all* functions in
a key_value database with unique names.

all functions in a key_value database with unique names

There’s a large part of me that wants to believe this could work. Yet the received wisdom is the opposite: modules facilitate independent development by encouraging loose coupling, and (following Conway’s law) make interfaces explicit between the people building the software. https://en.wikipedia.org/wiki/Conway%27s_law

Is loose coupling possible in a system where the 'functions' (or whatever the units of composition are) are stored in a db? In theory having two pieces of metadata attached to each function - a namespace and a private/public flag - seems equivalent to whatever benefit is provided by modules?

Web URLs (just like local file paths) are naming a location instead of identifying a particular content. If the particular content is at the location they're naming, everything's fine, but this is brittle. Think of unresolved imports, dll errors, 404s, ... These all happen because we're naming locations instead of content directly. In addition to the projects you mentioned, there's also IPFS which is pushing the idea of decentralized content-based addressing. I think that IPFS might be good candidate for a program representation that allows safe collaboration and sharing.

Forgot to mention another related project: farm/hypermerge (https://github.com/inkandswitch/farm)

I'd like to see a PL where modules / namespaces are purely metadata for humans and the actual "link" between function calls and definitions is a unique (content-based?) identifier. This would allow people to curate related functions as they like without breaking any programs. Organizations / communities could maintain such collections and individual people could create their own organization based on their favorite functions / packages, ...

And someone on the eutomerge slack mentionnd InfoCentral. "InfoCentral is an information-centered architecture for better software and a decentralizable internet. It is foremost concerned with data portability, semantics, and interoperability. "

Based on what @Ilari Kajaste said at https://futureofcoding.slack.com/archives/CLYCGTCPL/p1566286289184100?thread_ts=1566238710.155700&cid=CLYCGTCPL, it sounds like ValOS may be doing something interesting here as well.

"Why do we need modules at all?" In Curv, modules are first class values. They can be parameterized. You can have multiple implementations of the same API, each represented by a different module value, and you can pass these values as arguments or store them in data structures.

@Kartik Agaram Quite so. The valos resource space (we call it valospace for short) is indeed a fundamentally "shared" single world, even if it does consist of data that resides in different sources (authorities).