I'm into tools, so the weird language/environments I'd like to write include:
* A language where the program is constructed by editing a running process in-place with a debugger/IDE, then the process is "saved" as an executable.
* An iPad app that lets people draw dataflow programs with a pencil
* A SQL dialect that compiles to Kinesis streams and EC2 instances
Others mentioned Smalltalk, but this is exactly how Common Lisp, and many (most) other Lisps work.
In Common Lisp, you start with a process that has a compiler (or interpreter, depending on implementation) and a REPL, and everything you do from there is modifying that process, called "an image". After you're done, you can dump the image into a standalone executable (but unless you're distributing executables or care about startup time, it's not something you'll likely do). Source code in Lisp is really a set of operations you do on that image.
I'd like to use an external debugger, based on ptrace or the like, to accomplish the same development style, but without (necessarily) having any reflection in the program being developed, and without the need for tooling code comingled with program code.
It's been a few years, but this reminds me of learning Smalltalk back in the day, as well as how some Lisps (CL?) treat the VM as the program being produced
I am currently working on a variant of the Smalltalk image concept that works this way, based on Objective-Smalltalk[1] You have documents in a live coding environment, and those documents can be saved as executables.
One inspiration is DropScript[2], which was an app that converted Unix scripts into (simple) MacOS X apps. Another is obviously Smalltalk.
> An iPad app that lets people draw dataflow programs with a pencil
Objective-Smalltalk also has pretty good dataflow support. Drawing would be a reasonable addition.
I'm thinking of something that would be a lot like Smalltalk, but with strict separation between program and metaprogram. (In the spirit of Alan Kay's notion of fences between metaboundaries). The IDE would run in a separate process from the program, and attach to the program via operating system debugging facilities.
I think most of the problems with Smalltalk can be traced back to its origin as an operating system and the mingling of the program and tools for writing the program in the same image. Eg, shrink scripts for deployment.
That's an interesting approach, let me know how it works out!
In my previous efforts, I just used a small HTTP server inside the target program. You can see it in action here, fine-tuning an iOS target:
https://www.youtube.com/watch?v=ArcClqt2vTc
Since it's HTTP, it also works on the device. You can obviously also access those facilities from within the process, at least for a macOS app.
Right now, I am focusing on a more image-like user-experience, but with individual (small-ish) documents instead of a huge monolithic image. The difference in trying out UI-oriented idea compared to having to create a separate Xcode project each time is huge, and of course jut doing it live without restarting.
My guess is that these documents will evolve to be a lot like .frameworks, so code + resources. Budding an app is then no more than just copying the app shell and filling it with the right frameworks. (See Xcode). Once budded, you might interact via the HTTP route. Or maybe via debugger?
Why do people want this? I honestly don't understand. The point of code as opposed to just doing stuff by hand is that you can edit the code independently of its execution. You can fully inspect it without running it, and without any weird crevices for information to hide in. The workflow where you sort of edit and save processes, like smalltalk images, seems like it would throw away those advantages.
Another fun language which does this is Factor https://factorcode.org