4 ms·
I'm the author, was not expecting to see this here today, somebody posted it yesterday as well but got no traction. It's just a small essay about how I approach
by MarceColl 3y ago
I'm the author, was not expecting to see this here today, somebody posted it yesterday as well but got no traction. It's just a small essay about how I approach programming, particularly when understanding problems and exploring new ideas.
It's a little bit of explanation of a project I'm doing as well as something I'd have liked to read years ago when I was sure I was just doing it wrong.
- agumonkey 2y agoDo you have buddies or web acquaintances talking about similar ideas / goals ? I've always been searching for this mindset but I rarely read / hear about it.
- norman784 3y agoThis 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 agoUnison 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 agoYour 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 agoSomeone 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!
- isr 3y agoOn the off chance that you haven't yet looked at smalltalk, can I recommend cuis smalltalk as worthy of investigation. It's a simplified smalltalk (like pharo, forked from squeak), where the emphasis is on having a base system that you can reasonably fit in your head (think scheme vs common lisp). Here you'll find much of what you described, including per-method revision history. BTW, it comes with a rebuilt morphic gui with flawless scaling - unlike most smalltalk, this one actually looks crisp - even on large displays
- freethejazz 3y agoAnother take on non-linear explorational programming is Black, which is an extension of scheme. Different motivations, but you might find something interesting there. How I was exposed to it: https://m.youtube.com/watch?v=SrKj4hYic5A https://m.youtube.com/watch?v=SrKj4hYic5A