4 ms·

In my opinion the idea is more than direct data manipulation. It is about how we get feedback. In drawing, the medium to draw is the same medium to read. In pr

by a_c 4y ago

In my opinion the idea is more than direct data manipulation. It is about how we get feedback. In drawing, the medium to draw is the same medium to read. In programming, there is often a mismatch - coding on a text file, running on somewhere else, e.g. terminal, browser, remote server. If you count surrounding activities for programming, like versioning, debugging, metering and profiling, even more system is involved. We are not even touching the myriad of SaaS offering each tackling carve out a little pie out of the programming life cycle. Back to your question, from my naive understanding, smalltalk seems to be an all in one environment. The Glamorous Toolkit [1] seems to be that environment on steroid. I have no useful experience to share though. https://gtoolkit.com/ https://gtoolkit.com/

stefncb 4y ago
I think that's something inherent to programming. It's not even the only field to have this "problem" - screenplays are written on paper but watched on a stage. Movies are that, but with yet another level of indirection.
- ElevenLathe 4y ago
  Slightly off-topic but I've often daydreamed about a kind of Lisp-driven 3D Movie Maker (https://en.wikipedia.org/wiki/3D_Movie_Maker https://en.wikipedia.org/wiki/3D_Movie_Maker) where you could build movies from a REPL/SLIME the same way you do ordinary Lisp code -- evaluate a form, see the scene play out. With additions like modern text-to-speech and ML models generating meshes/textures, it could be a very pliable medium for a lone filmmaker to put together a movie all on their own, or even adopt a GitOps-y approach where multiple people (e.g. a script supervisor, cinematographer, light rigger) can collaborate through pull requests and code reviews.
  - stefncb 4y ago
    I've genuinely had the same general idea (minus the ML part), and I've started working on it once but abandoned it. I might get back on that some day. Another thing I considered was that, instead of the lisp, you'd have a math-y language and compose everything together. This has the added benefit that it compiles easily to GPU code. So like a chroma key thing would be a function that chooses one buffer over the other based on pixel color. You the compose that with other functions to create a frame. An APL-like language could be amazing here. I feel like there's _a lot_ of potential here.

by a_c 4y ago

stefncb 4y ago

I think that's something inherent to programming. It's not even the only field to have this "problem" - screenplays are written on paper but watched on a stage. Movies are that, but with yet another level of indirection.

ElevenLathe 4y ago
Slightly off-topic but I've often daydreamed about a kind of Lisp-driven 3D Movie Maker (https://en.wikipedia.org/wiki/3D_Movie_Maker https://en.wikipedia.org/wiki/3D_Movie_Maker) where you could build movies from a REPL/SLIME the same way you do ordinary Lisp code -- evaluate a form, see the scene play out. With additions like modern text-to-speech and ML models generating meshes/textures, it could be a very pliable medium for a lone filmmaker to put together a movie all on their own, or even adopt a GitOps-y approach where multiple people (e.g. a script supervisor, cinematographer, light rigger) can collaborate through pull requests and code reviews.
- stefncb 4y ago
  I've genuinely had the same general idea (minus the ML part), and I've started working on it once but abandoned it. I might get back on that some day. Another thing I considered was that, instead of the lisp, you'd have a math-y language and compose everything together. This has the added benefit that it compiles easily to GPU code. So like a chroma key thing would be a function that chooses one buffer over the other based on pixel color. You the compose that with other functions to create a frame. An APL-like language could be amazing here. I feel like there's _a lot_ of potential here.