4 ms·

This sounds much like how unison[0] works. I would say that if it were to use a C like syntax, the succeed chances would go up. Would be cool if it targets WAS

This sounds much like how unison[0] works. I would say that if it were to use a C like syntax, the succeed chances would go up. Would be cool if it targets WASM, this something I'm super interested right now, there are a lot of advantages on targeting WASM one of them is the interoperability with other components written in different languages, this will be when the component model[1] get's finished and implemented. [0]http://unison-lang.org http://unison-lang.org [1]https://component-model.bytecodealliance.org https://component-model.bytecodealliance.org

MarceColl 3y ago
Unison was very much an inspiration for my thoughts, but statement based programming (C-syntax) is pretty much out of the question since they rely on hashing functions and on some specific ways of specifying computation so it can work as it does with the whole distribution of computation and universal database of code. It is actually one of the problems I have with common lisp, its impossible to do a semantic hash on arbitrary common lisp functions so I create more history that I need, since a reordering of independent let forms cannot be easily detected to preserve functionality
- brabel 3y ago
  Your ideas sounded very much like a mixup of Common Lisp with SLIME, Smalltalk interactivity and Unison-like storage of code in a database instead of files. I've tried all of them, I think the closest thing I've seen to what you describe, which I also find very attractive, is the GT Smalltalk environment: https://gtoolkit.com/ https://gtoolkit.com/ Have you tried that? They call this idea "moldable development" as you can "mold" your environment to your needs. Even though I loved it, I ended up not using it much, mostly because it's a bit too heavy to keep handy for exploration all the time when needed (it takes like 1GB of RAM even when idle!)... as I already can do most of that with emacs, which is much lighter, I just stick with it.
  - deleted 3y ago
    [deleted]
  - MarceColl 3y ago
    Someone sent an email last night about gtoolkit, I didn't know about it and I wanna try it. Right now I'm following another suggestion with Interlisp that also had some similar ideas, but that will come right after! Thanks for the suggestion!

MarceColl 3y ago

Unison was very much an inspiration for my thoughts, but statement based programming (C-syntax) is pretty much out of the question since they rely on hashing functions and on some specific ways of specifying computation so it can work as it does with the whole distribution of computation and universal database of code. It is actually one of the problems I have with common lisp, its impossible to do a semantic hash on arbitrary common lisp functions so I create more history that I need, since a reordering of independent let forms cannot be easily detected to preserve functionality

brabel 3y ago
Your ideas sounded very much like a mixup of Common Lisp with SLIME, Smalltalk interactivity and Unison-like storage of code in a database instead of files. I've tried all of them, I think the closest thing I've seen to what you describe, which I also find very attractive, is the GT Smalltalk environment: https://gtoolkit.com/ https://gtoolkit.com/ Have you tried that? They call this idea "moldable development" as you can "mold" your environment to your needs. Even though I loved it, I ended up not using it much, mostly because it's a bit too heavy to keep handy for exploration all the time when needed (it takes like 1GB of RAM even when idle!)... as I already can do most of that with emacs, which is much lighter, I just stick with it.
- deleted 3y ago
  [deleted]
- MarceColl 3y ago
  Someone sent an email last night about gtoolkit, I didn't know about it and I wanna try it. Right now I'm following another suggestion with Interlisp that also had some similar ideas, but that will come right after! Thanks for the suggestion!