4 ms·

Ooh. Dependent types and borrow checking. Yes please. I'm into tools, so the weird language/environments I'd like to write include: * A language where the pro

• mhluongo 7y ago
  > 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. 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
  • protomyth 7y ago
    I knew a couple of Smalltalkers that would write their programs in the debugger. Its pretty good for rapidly figuring out what you need to get the job done, and then they would go back with the refactoring browser to clean it up and get it in line with the rest of the system.
    • barrkel 7y ago
      This is generally how I write Ruby, using pry.
    • cjbprime 7y ago
      Yeah, I think Squeak is distributed this way, as a VM image.
  • 4thaccount 7y ago
    Smalltalk is like this and so is SBCL with Emacs Slime mode.
• andrewflnr 7y ago
  > 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. 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.
  • rabidrat 7y ago
    It allows rapid productization by combining experimentation and development into a single process. The dream is to do something just once manually, and then have it automated with no further effort. This is why Excel is one of the most used programming environments.
• mpweiher 7y ago
  > editing a running process in-place with a debugger/IDE, then the process is "saved" as an executable 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. [1] http://objective.st http://objective.st [2] http://www.wsanchez.net/papers/DropScript/ http://www.wsanchez.net/papers/DropScript/
  • cwp 7y ago
    Hi Marcel! 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.
    • mpweiher 7y ago
      > via operating system debugging facilities. 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 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?
• ewhauser421 7y ago
  Google announced Dataflow SQL recently. Not too many details on it yet but should be close to what you want
• TeMPOraL 7y ago
  > 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. 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.
  • cwp 7y ago
    Sorry, I should have given more detail. Both Smalltalk and Lisp use reflection for editing in place. The IDE, or REPL, is part of the process being edited. 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.
• chriswarbo 7y ago
  > 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. Another fun language which does this is Factor https://factorcode.org https://factorcode.org
  • javajosh 7y ago
    I don't have first-hand knowledge of it, but I understand that Smalltalk was/is developed like this - and it has significant drawbacks.