5 ms·

It's kind of depressing, honestly. Smalltalk is amazing future technology from the 1980s, and here we are in 2022 with our fancy IDEs still dropping off our (me

It's kind of depressing, honestly. Smalltalk is amazing future technology from the 1980s, and here we are in 2022 with our fancy IDEs still dropping off our (metaphorical) punch cards for batch processing.

tluyben2 4y ago
Yep... Fairly bizar that a smalltalk env on an old computer is faster for iteration than the modern react/typescript stack. Better errors, easier to debug etc. All because the tooling was from the future. React peeps think hot reload is something special. It was normal and it was faster and more robust than it is now.
- nyanpasu64 4y ago
  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?
coliveira 4y ago
The problem is that developers have been brainwashed to dislike what Smalltalk has to offer. If you tell them to use a Smalltalk-like system they will complain to no end about the lack of file-centric infrastructure, while what Smalltalk has to offer is decades ahead of what they can do with other systems.
- harha 4y ago
  Any recommendations on where to get started to understand the idea behind it, where it’s used and how to approach typical problems?
- rscho 4y ago
  In a much less interactive manner, the Unison language seems like it revolves around some stuff found in Smalltalk
- agumonkey 4y ago
  market dynamics wiped lisp in the 80s, then smalltalk in the 90s such is life, it's gonna popup again in php10 or typescript5 for sure
- TheAceOfHearts 4y ago
  How is version control usually handled in these kinds of systems?
  - melvinroest 4y ago
    <= Pharo 8: Monticello >= Pharo 9: Git (through something called Iceberg)
  - throwawayForMe2 4y ago
    When I did Smalltalk in a corporate team environment we used a tool called Team/V. Code is stored in a shared repository. Everyone starts with the same clean image, loaded with the tools and options chosen for the project. From your clean running image, you open the Repository Browser window. You load app code from the repository, make changes etc., and commit back to the shared repository. There were many options for organizing “packages” and creating lists of packages and version numbers for a “build”. Also different options for ownership of code, locking code from changes, difference reports, etc. Open source tools I have not used.

tluyben2 4y ago

Yep... Fairly bizar that a smalltalk env on an old computer is faster for iteration than the modern react/typescript stack. Better errors, easier to debug etc. All because the tooling was from the future. React peeps think hot reload is something special. It was normal and it was faster and more robust than it is now.

nyanpasu64 4y ago
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?

coliveira 4y ago

The problem is that developers have been brainwashed to dislike what Smalltalk has to offer. If you tell them to use a Smalltalk-like system they will complain to no end about the lack of file-centric infrastructure, while what Smalltalk has to offer is decades ahead of what they can do with other systems.

harha 4y ago
Any recommendations on where to get started to understand the idea behind it, where it’s used and how to approach typical problems?
rscho 4y ago
In a much less interactive manner, the Unison language seems like it revolves around some stuff found in Smalltalk
agumonkey 4y ago
market dynamics wiped lisp in the 80s, then smalltalk in the 90s such is life, it's gonna popup again in php10 or typescript5 for sure
TheAceOfHearts 4y ago
How is version control usually handled in these kinds of systems?
- melvinroest 4y ago
  <= Pharo 8: Monticello >= Pharo 9: Git (through something called Iceberg)
- throwawayForMe2 4y ago
  When I did Smalltalk in a corporate team environment we used a tool called Team/V. Code is stored in a shared repository. Everyone starts with the same clean image, loaded with the tools and options chosen for the project. From your clean running image, you open the Repository Browser window. You load app code from the repository, make changes etc., and commit back to the shared repository. There were many options for organizing “packages” and creating lists of packages and version numbers for a “build”. Also different options for ownership of code, locking code from changes, difference reports, etc. Open source tools I have not used.