5 ms·

> Value Database > Smalltalk and another esoteric programming environment I used for a while called Frontier had an idea of a persistent data store environment

> Value Database > Smalltalk and another esoteric programming environment I used for a while called Frontier had an idea of a persistent data store environment. Basically, you could set global.x = 1, shut your program down, and start it up again, and it would still be there. Frontier! I played with that way back when on the Mac. Fun times. But as for programming language with integrated database... MUMPS! Basically a whole language and environment (and, in the beginning, operating system) built around a built-in global database. Any variable name prefixed with ^ is global and persistent, with a sparse multi-dimensional array structure to be able to organize and access the variables (e.g. ^PEOPLE(45,"firstname") could be "Matthew" for the first name of person ID 45). Lives on today in a commercial implementation from Intersystems, and a couple Free Software implementations (Reference Standard M, GT.M, and the GT.M fork YottaDB). The seamless global storage is really nice, but the language itself is truly awful.

SeenNotHeard 2y ago
TADS, an OOP language + VM for interactive fiction, has this "value database" model. Once loaded into memory, the compiled image can be updated with values stored in a separate save file. The compiled image itself could store updated values as well. In fact, it does this during a "preinit" stage that runs immediately after compilation. Once all preinit code finishes executing, the compiled image is overwritten with the updated state. The language includes a "transient" keyword to permit creating objects that should not be stored. This same mechanism permits in-memory snapshots, which are used for the game's UNDO feature. No need to rewind or memento-ize operations, just return to a previous state. It's not a general-purpose mechanism. After all, the language is for building games with multiple player-chosen save files, and to permit restarting the game from a known Turn 0 state.
jonathaneunice 2y ago
Image persistence was one of the cool ideas of Smalltalk. And in practice, one of the biggest drawbacks. Cruft and old values accumulated steadily, with very little way to find and eliminate them. Transient execution has some cons. But on the pro side, every run starts from a "clean slate."
- brabel 2y ago
  > with very little way to find and eliminate them. The best Smalltalk these days is GlamorousToolkit: https://gtoolkit.com/ https://gtoolkit.com/ It has a sort of git in it, so you can easily "rollback" your image to previous states. So going back and forth in history is trivial.
  - galaxyLogic 2y ago
    > you can easily "rollback" your image to previous states. Sounds very interesting. Does it support multi-developer merging and/or rebasing of changes?
    - brabel 2y ago
      I believe it's just a git repo behind the scenes. Not sure if the UI exposes those things as I never used that in multi-developer scenarios! Give it a go and see.
- igouy 2y ago
  And in practice, both. Save image... for short-term convenience; build clean every week from archived text files. ---- 1984 "Smalltalk-80 The Interactive Programming Environment" page 500 "At the outset of a project involving two or more programmers: Do assign a member of the team to be the version manager. … The responsibilities of the version manager consist of collecting and cataloging code files submitted by all members of the team, periodically building a new system image incorporating all submitted code files, and releasing the image for use by the team. The version manager stores the current release and all code files for that release in a central place, allowing team members read access, and disallowing write access for anyone except the version manager." https://rmod-files.lille.inria.fr/FreeBooks/TheInteractiveProgrammingEnv/TheInteractiveProgrammingEnv.pdf https://rmod-files.lille.inria.fr/FreeBooks/TheInteractivePr...
  - jimbokun 2y ago
    So the "version manager" is a human git repository!
kweingar 2y ago
The MUMPS database is wild. When I was working in MUMPS, it was so easy and fun to whip up an internal tool to share with my coworkers. You don't have to give any special thought at all to persistence, so you're able to stay in the flow of thinking about your business logic. But as you said, the language itself is almost unbearable to use.
- danielhlockard 2y ago
  I had a professor who is responsible for a lot of the more "modern" MUMPS stuff (lets be real, MUMPS is OLD!). Guy was pretty unbearable too.

SeenNotHeard 2y ago

TADS, an OOP language + VM for interactive fiction, has this "value database" model. Once loaded into memory, the compiled image can be updated with values stored in a separate save file. The compiled image itself could store updated values as well. In fact, it does this during a "preinit" stage that runs immediately after compilation. Once all preinit code finishes executing, the compiled image is overwritten with the updated state. The language includes a "transient" keyword to permit creating objects that should not be stored. This same mechanism permits in-memory snapshots, which are used for the game's UNDO feature. No need to rewind or memento-ize operations, just return to a previous state. It's not a general-purpose mechanism. After all, the language is for building games with multiple player-chosen save files, and to permit restarting the game from a known Turn 0 state.

jonathaneunice 2y ago

Image persistence was one of the cool ideas of Smalltalk. And in practice, one of the biggest drawbacks. Cruft and old values accumulated steadily, with very little way to find and eliminate them. Transient execution has some cons. But on the pro side, every run starts from a "clean slate."

brabel 2y ago
> with very little way to find and eliminate them. The best Smalltalk these days is GlamorousToolkit: https://gtoolkit.com/ https://gtoolkit.com/ It has a sort of git in it, so you can easily "rollback" your image to previous states. So going back and forth in history is trivial.
- galaxyLogic 2y ago
  > you can easily "rollback" your image to previous states. Sounds very interesting. Does it support multi-developer merging and/or rebasing of changes?
  - brabel 2y ago
    I believe it's just a git repo behind the scenes. Not sure if the UI exposes those things as I never used that in multi-developer scenarios! Give it a go and see.
igouy 2y ago
And in practice, both. Save image... for short-term convenience; build clean every week from archived text files. ---- 1984 "Smalltalk-80 The Interactive Programming Environment" page 500 "At the outset of a project involving two or more programmers: Do assign a member of the team to be the version manager. … The responsibilities of the version manager consist of collecting and cataloging code files submitted by all members of the team, periodically building a new system image incorporating all submitted code files, and releasing the image for use by the team. The version manager stores the current release and all code files for that release in a central place, allowing team members read access, and disallowing write access for anyone except the version manager." https://rmod-files.lille.inria.fr/FreeBooks/TheInteractiveProgrammingEnv/TheInteractiveProgrammingEnv.pdf https://rmod-files.lille.inria.fr/FreeBooks/TheInteractivePr...
- jimbokun 2y ago
  So the "version manager" is a human git repository!

kweingar 2y ago

The MUMPS database is wild. When I was working in MUMPS, it was so easy and fun to whip up an internal tool to share with my coworkers. You don't have to give any special thought at all to persistence, so you're able to stay in the flow of thinking about your business logic. But as you said, the language itself is almost unbearable to use.

danielhlockard 2y ago
I had a professor who is responsible for a lot of the more "modern" MUMPS stuff (lets be real, MUMPS is OLD!). Guy was pretty unbearable too.