4 ms·

I think there's an inherent conflict between languages creating programs like clay to be molded by the developer and the user, interactively (repl, smalltalk),

I think there's an inherent conflict between languages creating programs like clay to be molded by the developer and the user, interactively (repl, smalltalk), vs. languages creating programs with optimal machine code with no extraneous computations, and/or maximal low-level control (sometimes even at the cost of making it harder to alter code, like manual data structures or hand-rolled assembly or vectorization). I wouldn't call Smalltalk technology from the future, but rather optimizing for a different ideal (though I've never used Smalltalk to experience the magic firsthand (and/or smoke and mirrors, ctrl+f "white/blacklisting")). Smalltalk (like Java) is bound to a GC, and GC wreaks havoc with using finalizers for manual memory management cleanup, since finalizers can be called while a variable is still in scope unless you use GC.KeepAlive() or friends. On the other hand, optimized C++ is notoriously hard to debug, and debug C++ is slow (especially when using "zero overhead" abstractions that are only zero-overhead in release builds). There's cool work at reversible debugging, binary-patching, etc. (low-overhead tracepoints, Linux kernel Kprobes which failed to hook some functions I think were actually called, CONFIG_DYNAMIC_FTRACE, most recently https://justine.lol/ftrace/ https://justine.lol/ftrace/, though both CONFIG_DYNAMIC_FTRACE and ftrace depend on injecting nops into code which can later be replaced by tracing code). JavaScript excels at neither performance nor dynamism, though I think it's still a lot more dynamic than C++ (userscripts can tamper with page contents and scripting) and faster than Python (through herculean effort of the V8 developers funded by Google ad revenue to make web apps and advertising faster). And C++/assembly, by its nature of allowing complete control over the machine, is difficult to sandbox beyond running code in an isolated process or VM (or compiling to WASM then to x86?), as opposed to JS/WASM being (theoretically) memory-safe and sandboxable by taking away APIs interfacing to the outside world.

tluyben2 4y ago
We are trying to do something novel on this intersection you speak of. I hope we figure it out far enough. But yes, you are right in sketching the current situation; I firmly believe we could’ve been a lot further than we are and I intend to prove it.
eismcc 4y ago
While this is a deep topic regarding the philosophical break between the two paradigms and one which I spend a lot of time on, the ideal to me seems to be a system which has the immersive nature of a smalltalk-like environment while having the finalized image run at near “chip speeds”. JIT was added to smalltalk to solve this problem and so I wonder if it’s more about balancing the two modes.
- scroot 4y ago
  There is also just the simple issue of how many people are working on these systems. Right now there is an Opensmalltalk VM change in the words -- SISTA -- that has the potential for a 3x speedup of those systems. But it's largely the work of one or two people and it's unfunded. They are working on it in their limited free time. Additionally, there is a specific kind of dominant "computing culture" that we live in. Show a new language to mainstream developers and they will want to know how to do a "hello world" and which text editor / command line program to run in order to use it, as if these are the only ways to interact with a machine in any meaningful way. Anything outside of this seems like it's "not real programming".
- mncharity 4y ago
  > the philosophical break between the two paradigms and one which I spend a lot of time on [...] I wonder if it’s more about balancing the two modes. I don't see the break? "Clay" tooling exists for "industrial" code, but as secret sauce, and jig kludgery, and various other "making this more broadly available is not in/of our interest". "Clay"'s rejection of "industrial" has seemed more resource-starved exploit-not-explore group-think. Smalltalk/forth/etc audacious-scope rewrite-the-world efforts have seemed more "remake the world" than "to force us to remake ourselves". Try imaging a forth implementation effort that said "ok, we have bootstrap... so now the next obvious steps are supporting PICs and multiple dispatch and template jit, WAM and BEAM vms, linking Z3 solver, DHM type inference, ...". So perhaps rather than an inherent break between modes, and balancing to be done, there's a lack of available power, and of interests/resources aligned with ramping it. But then, I'd like a programming environment which provides an powerful environment for making engineering tradeoffs, rather than ones which hardwire in very dramatic ones. I expect such an environment, when it finally exists, won't be hard to recognize. As, for example, basic reimplementation of existing modern languages, with their big test suites, libraries, community repos, specs sometimes transliteratable directly into code, code-as-documentation and highly-investment-in optimization, is a natural forcing-factor exercise for such an environment. So when you see a small team spewing new language implementations... maybe we've at long last hit phase transition. And if one can't easily manage that, in bulk, even with all that leverage... then it's not a very powerful environment, is it?
mikelevins 4y ago
I think that saying it's an inherent conflict is overstating it. I think it's a bit more like there are these two axes, a performance axis and a malleability axis, and they aren't completely orthogonal, but they also aren't diametrically opposed. Granted, if you ignore one axis and optimize the heck out of the other one, you're unlikely to end up in an optimal region of the ignored axis. But there are optimization paths that move in good directions on both axes at once, until you reach some limit where you sort of move around on some boundary arc by trading off one against the other. Apple's Dylan project was conceived with the explicit purpose of developing a language and runtime that would satisfy the highly-interactive-programming enthusiasts (that is, the Smalltalkers and Lispers) in Apple's ATG and other researchy groups, while also producing built artifacts that were fast and interop-friendly and compact enough that they wouldn't all have to be rewritten from scratch in C, Pascal, or assembly before the product groups would agree to ship them. The Dylan team did a pretty good job. I was one of their internal customers, working on an experimental handheld OS written mostly in Dylan. The Dylan team gave us a modified version of Macintosh Common Lisp, called Leibniz, with Dylan support. Leibniz was just MCL, but with a Dylan compiler, object system, and runtime built into it. The Dylan compiler cross-compiled to the handheld's hardware. Our dev machines were Macs, either with daughterboards stuck into nubus slots, or with actual handheld hardware ribbon-cabled to the nubus. Leibniz had a second version of everything in the MCL environment: there were the normal Lisp listener windows, but also Dylan listener windows. There were normal Lisp editor windows and Dylan editor windows. And so on. Code compiled and evaluated in the Lisp windows ran on the Mac hardware. Code compiled and evaluated in the Dylan windows ran on the handheld hardware. Our built software ran on the same handheld hardware as the C++ OS. It performed well--well enough to make some of the C++ team curious sometimes about how we did certain things. The relevant point is that you can make a highly-interactive and malleable language and development environment that also delivers fast, compact artifacts. I don't think there's an irresolvable tension between those two goals. On the other hand, optimizing toward both goals is more work than optimizing one at the expense of the other. If you elevate one goal above the other, the elevated goal will benefit and the other will suffer. Optimizing both means paying attention to both all the time, and that sometimes means that you will disqualify certain options. Optimizing both shrinks the workable solution space, so you have to look harder and sometimes solve problems in less easy ways than you would if you were thinking only about the one goal. On top of that, the features that make an environment a great, malleable, highly-interactive environment are extra. You still have to do all the same kind of work that you need if you don't care about making a highly-interactive environment--lexers, parsers, compilers, optimizers, linkers, editors, indexers, and so on, and so forth--but on top of that, you have to design and build all of the features that make an environment highly interactive--a repl that has visibility into everything in the runtime as it runs, error handling that can spin up an interactive session in the dynamic context of a signaled error, runtime facilities that detect and keep track of every dependency that changes dynamically and knows what to do about it, inspectors that know how to expose and edit every element of state in the whole system, and so on. That's really the obstacle, I think: a really malleable environment is just a lot more work. That, and to build one you need builders who know what they are and how to build them.

tluyben2 4y ago

We are trying to do something novel on this intersection you speak of. I hope we figure it out far enough. But yes, you are right in sketching the current situation; I firmly believe we could’ve been a lot further than we are and I intend to prove it.

eismcc 4y ago

While this is a deep topic regarding the philosophical break between the two paradigms and one which I spend a lot of time on, the ideal to me seems to be a system which has the immersive nature of a smalltalk-like environment while having the finalized image run at near “chip speeds”. JIT was added to smalltalk to solve this problem and so I wonder if it’s more about balancing the two modes.

scroot 4y ago
There is also just the simple issue of how many people are working on these systems. Right now there is an Opensmalltalk VM change in the words -- SISTA -- that has the potential for a 3x speedup of those systems. But it's largely the work of one or two people and it's unfunded. They are working on it in their limited free time. Additionally, there is a specific kind of dominant "computing culture" that we live in. Show a new language to mainstream developers and they will want to know how to do a "hello world" and which text editor / command line program to run in order to use it, as if these are the only ways to interact with a machine in any meaningful way. Anything outside of this seems like it's "not real programming".
mncharity 4y ago
> the philosophical break between the two paradigms and one which I spend a lot of time on [...] I wonder if it’s more about balancing the two modes. I don't see the break? "Clay" tooling exists for "industrial" code, but as secret sauce, and jig kludgery, and various other "making this more broadly available is not in/of our interest". "Clay"'s rejection of "industrial" has seemed more resource-starved exploit-not-explore group-think. Smalltalk/forth/etc audacious-scope rewrite-the-world efforts have seemed more "remake the world" than "to force us to remake ourselves". Try imaging a forth implementation effort that said "ok, we have bootstrap... so now the next obvious steps are supporting PICs and multiple dispatch and template jit, WAM and BEAM vms, linking Z3 solver, DHM type inference, ...". So perhaps rather than an inherent break between modes, and balancing to be done, there's a lack of available power, and of interests/resources aligned with ramping it. But then, I'd like a programming environment which provides an powerful environment for making engineering tradeoffs, rather than ones which hardwire in very dramatic ones. I expect such an environment, when it finally exists, won't be hard to recognize. As, for example, basic reimplementation of existing modern languages, with their big test suites, libraries, community repos, specs sometimes transliteratable directly into code, code-as-documentation and highly-investment-in optimization, is a natural forcing-factor exercise for such an environment. So when you see a small team spewing new language implementations... maybe we've at long last hit phase transition. And if one can't easily manage that, in bulk, even with all that leverage... then it's not a very powerful environment, is it?

mikelevins 4y ago

I think that saying it's an inherent conflict is overstating it. I think it's a bit more like there are these two axes, a performance axis and a malleability axis, and they aren't completely orthogonal, but they also aren't diametrically opposed. Granted, if you ignore one axis and optimize the heck out of the other one, you're unlikely to end up in an optimal region of the ignored axis. But there are optimization paths that move in good directions on both axes at once, until you reach some limit where you sort of move around on some boundary arc by trading off one against the other. Apple's Dylan project was conceived with the explicit purpose of developing a language and runtime that would satisfy the highly-interactive-programming enthusiasts (that is, the Smalltalkers and Lispers) in Apple's ATG and other researchy groups, while also producing built artifacts that were fast and interop-friendly and compact enough that they wouldn't all have to be rewritten from scratch in C, Pascal, or assembly before the product groups would agree to ship them. The Dylan team did a pretty good job. I was one of their internal customers, working on an experimental handheld OS written mostly in Dylan. The Dylan team gave us a modified version of Macintosh Common Lisp, called Leibniz, with Dylan support. Leibniz was just MCL, but with a Dylan compiler, object system, and runtime built into it. The Dylan compiler cross-compiled to the handheld's hardware. Our dev machines were Macs, either with daughterboards stuck into nubus slots, or with actual handheld hardware ribbon-cabled to the nubus. Leibniz had a second version of everything in the MCL environment: there were the normal Lisp listener windows, but also Dylan listener windows. There were normal Lisp editor windows and Dylan editor windows. And so on. Code compiled and evaluated in the Lisp windows ran on the Mac hardware. Code compiled and evaluated in the Dylan windows ran on the handheld hardware. Our built software ran on the same handheld hardware as the C++ OS. It performed well--well enough to make some of the C++ team curious sometimes about how we did certain things. The relevant point is that you can make a highly-interactive and malleable language and development environment that also delivers fast, compact artifacts. I don't think there's an irresolvable tension between those two goals. On the other hand, optimizing toward both goals is more work than optimizing one at the expense of the other. If you elevate one goal above the other, the elevated goal will benefit and the other will suffer. Optimizing both means paying attention to both all the time, and that sometimes means that you will disqualify certain options. Optimizing both shrinks the workable solution space, so you have to look harder and sometimes solve problems in less easy ways than you would if you were thinking only about the one goal. On top of that, the features that make an environment a great, malleable, highly-interactive environment are extra. You still have to do all the same kind of work that you need if you don't care about making a highly-interactive environment--lexers, parsers, compilers, optimizers, linkers, editors, indexers, and so on, and so forth--but on top of that, you have to design and build all of the features that make an environment highly interactive--a repl that has visibility into everything in the runtime as it runs, error handling that can spin up an interactive session in the dynamic context of a signaled error, runtime facilities that detect and keep track of every dependency that changes dynamically and knows what to do about it, inspectors that know how to expose and edit every element of state in the whole system, and so on. That's really the obstacle, I think: a really malleable environment is just a lot more work. That, and to build one you need builders who know what they are and how to build them.