I've been considering writing a "programming system of the future, backwards-compatible with the cranky programmers of today" by having just such a relational (or key-value) underlying representation... and then a FUSE server that presents an editable filesystem+text view of it.
Among a thousand other benefits, the "cutest" one is that all code gets canonicalized on save. The filesystem will literally reject a write(3) that can't be translated into a valid AST to be stored into the underlying DB. It's like a super-powered version of running "go fmt" as a git pre-commit hook.
Re:Why do we need modules at all? (2011)
by vezzy-fnord on Sunday October 18, 2015 @05:29PM
(#10409864)
RelFS was an experiment circa 2004-2005 in blending RDBMS with FUSE: http://relfs.sourceforge.net/
Re:Why do we need modules at all? (2011)
by weinzierl on Sunday October 18, 2015 @04:58PM
(#10409758)
This has been done before but it didn't take hold. As far as I know the most successful and widespread attempt in this direction was IBM's Visual Age.
Eclipse is based on Visual Age but did away with the source code data base.
Re:Why do we need modules at all? (2011)
by ddouglascarr on Sunday October 18, 2015 @05:23PM
(#10409834)
Modules as views on this database of functions is genius.
Most of the problems that Joe talks about with modules go away if modules become just a mutable collection of functions, and functions can be in more than one module.
You can keep your cake and eat it too!
Re:Why do we need modules at all? (2011)
by moron4hire on Sunday October 18, 2015 @05:39PM
(#10409908)
Only if the relationship between functions needs to be a directed graph. If a strict tree with no cross connections is sufficient, then there should be no reason for two classical modules to share identical functions. The existence of such a function would suggest instead the need for a third module.
Considering the idea of functions that need a directed graph to describe their relationships makes it pretty obvious, at least to me, that it's a bad idea.
Modules can then be views and I think they would still be useful. I think the coincidence we currently have where modules are files makes it seem like mutual exclusivity and tree-like hierarchy is a defining feature of modules. We can throw that out. I think a lot of Joe Armstrong's complaints go away now.
Modules are still useful for human purposes. They are useful units of responsibility, accountability, maintenance, learning, and presentation. In fact, these facets of modules are enhanced if modules can intersect as views into a codebase: Overlap and dependence of code can be modeled as intersections and joins of modules-as-views. That these can be computed from the structure of code rather than implicitly understood on top of the directory hierarchy of a file system, or worse, forcibly mangled to fit into a tree-like hierarchy like files is a tantalizing possibility.