4 ms·

I think this is an awesome idea. I really like the Smalltalk approach of not using files and instead representing the structure of a program purely in memory. I

I think this is an awesome idea. I really like the Smalltalk approach of not using files and instead representing the structure of a program purely in memory. I also love the idea of drawing inspiration from spreadsheets and databases instead of representing programs purely in lines of code. I applaud this effort and can't wait to try it out!

jagged-chisel 7y ago
Any long-lived executable sits in memory (notwithstanding paging, which the database server is also subject to), and such an executable is free to maintain any files it accesses in memory as well.
- gnode 7y ago
  I think what was being referred to is the technique of defining a program, not as source code files which are then compiled/run in an interpreter, but as an in-memory VM environment (think REPLs). The memory-based environment can then be saved to a file, similar to making a core dump. This changes the structure of programs from a file/disk based structure, to the potentially richer structure of the programming environment (e.g. graphs of objects). Although it comes with disadvantages like losing the tool inter-operability of files.
  - bernawil 7y ago
    That sounds like doing for code what we used to do for deployments before docker/kubernetes. Like going back from a declarative and reproducible aproach to a more procedural one. There's good reasons infrastructure as code took hold.
  - breck 7y ago
    I have a hard time seeing advantages of ditching files. I like this concept, but you can have it both ways (come up with a graphical notation that you can then manipulate with graph like tools), but at the end of the day you need a source of truth, and the file metaphor (a named region of code) is hard to beat (impossible to beat?). Even databases store things as files.
    - gnode 7y ago
      File systems are just one approach to storage. Databases can use file systems, block devices, or object-based storage (such as distributed storage systems, e.g. Ceph, Amazon S3). Traditional file systems are, by themselves, inadequate for many use case, as they don't provide things like versioning. The strength of the file system, is that much tooling already exists for it.

jagged-chisel 7y ago

Any long-lived executable sits in memory (notwithstanding paging, which the database server is also subject to), and such an executable is free to maintain any files it accesses in memory as well.

gnode 7y ago
I think what was being referred to is the technique of defining a program, not as source code files which are then compiled/run in an interpreter, but as an in-memory VM environment (think REPLs). The memory-based environment can then be saved to a file, similar to making a core dump. This changes the structure of programs from a file/disk based structure, to the potentially richer structure of the programming environment (e.g. graphs of objects). Although it comes with disadvantages like losing the tool inter-operability of files.
- bernawil 7y ago
  That sounds like doing for code what we used to do for deployments before docker/kubernetes. Like going back from a declarative and reproducible aproach to a more procedural one. There's good reasons infrastructure as code took hold.
- breck 7y ago
  I have a hard time seeing advantages of ditching files. I like this concept, but you can have it both ways (come up with a graphical notation that you can then manipulate with graph like tools), but at the end of the day you need a source of truth, and the file metaphor (a named region of code) is hard to beat (impossible to beat?). Even databases store things as files.
  - gnode 7y ago
    File systems are just one approach to storage. Databases can use file systems, block devices, or object-based storage (such as distributed storage systems, e.g. Ceph, Amazon S3). Traditional file systems are, by themselves, inadequate for many use case, as they don't provide things like versioning. The strength of the file system, is that much tooling already exists for it.