6 ms·

I find Ruby to be enough of a Smalltalk for my taste. Besides that I see people to stuff with Clojure, such as hot-replacing live code, that I had only seen Sma

by cies 5y ago

I find Ruby to be enough of a Smalltalk for my taste. Besides that I see people to stuff with Clojure, such as hot-replacing live code, that I had only seen Smalltalk devs do so far.

disconcision 5y ago
related, see this clojure talk on image-based programming in a functional context: https://www.youtube.com/watch?v=Kgw9fblSOx4 https://www.youtube.com/watch?v=Kgw9fblSOx4
weatherlite 5y ago
So what are the similarities between Ruby and Smalltalk? I'm probably never gonna learn Smalltalk so it's hard to understand what Ruby borrowed.
- Mikeb85 5y ago
  Everything is an object. Being able to inspect/change running objects, etc...
- cies 5y ago
  I feel Ruby is mostly another syntax, but the type of OO (with bits of FP where it makes sense in OO) is very much like Smalltalk the language.
0x445442 5y ago
I don't have experience with Ruby or Clojure. While you're debugging an app, can you step to a break point, evaluate the next statement, navigate back up the call stack, change code that's already executed and try again in those languages?
- vidarh 5y ago
  To an extent. Things like "pry" in Ruby will let you edit methods and reload and resume and generally somewhat pretend you're working on an image. It's not as flexible as a typical Smalltalk environment, but with the new Ruby debugger in Ruby 3.1 I suspect we'll see another big leap towards that.
- phyrex 5y ago
  Common Lisp lets you do that, but Clojure doesn't - I don't know about Ruby, but I expect not. That said, you have the wrong mental model. You don't run the whole program and set breakpoints. Instead you directly interact with your program-space. Imagine you have a function that retrieves something from an API. So you execute that function and see what it returns. You change that data around a little to fit your usecase, and then hand it off to the function that acts on the API result. That will produce more data; maybe this data is wrong, so you change the function, recompile it and load it into the program space, and try again with the same data you just changed (which is still right there in the variable you defined). Does that make it clearer?
vidarh 5y ago
"pry" in many ways try to borrow even more of Smalltalk into Ruby. E.g. the ability to inspect a running system and bring up an editor to edit a specific method and then load the result into the running system, for example. I often bootstrap experimental code with pry "built in" in various ways, e.g. with a small "prolog" with a few utility methods to hot-reload the code and set up basics to let me keep an editor in one window a pry session in another, make changes and just load the changes without dropping the current state so I can get instant feedback using the test data I already have loaded. For the last two years or so I've used a text editor I wrote in Ruby instead of emacs which spins up a server process on first start that it then exposes via DrB (an IPC library for those not familiar with Ruby) that stores the contents of the buffers and persists them regularly. I did that both so I can implement multiple views on the same buffer without having the same client process keep everything open, and so that if anything crashes I'm unlikely to lose data. But the side effect is that because DrB forwards exceptions too, and the editor itself is set up to catch all exceptions and throw me into pry, if something crashes my editor, I get a pry prompt where I can live-debug it on the real buffers, edit the editor with another instance of itself talking to the same backend server instance, and then hot-replace the code to see if it fixes the bug. For hard-to-reproduce bugs in particular it's amazing to be able to keep the buggy instance running while fixing the problem and figuring out which conditions causes it.
- cies 5y ago
  I really like this, but I also like strong typing, and somehow it feels I cannot have both. Smalltalk, Ruby, LISPs (Clojure) in one corner A, and Rust, Haskell, OCaml/ReasonML/Rescript, Elm, PureScript in the other corner B. A: quick to "compile", so fast write-run-try loops, very runtime inspectable/updatable, less noisy syntax; but also easier to make runtime errors, larger test suites, less easy to refactor. B: refactorability (especially with good IDE support), strong runtime correctness guarantees; but also long compile times, and no cool runtime inspection/update wizzardry.
  - vidarh 5y ago
    Ruby is strongly typed. So is Smalltalk. It is not statically typed, so given a variable you can not know from the variable which type it currently holds. But in Ruby you can always know from the object itself which type it is. That said there's a lot of work going on in Ruby to allow you to get more certainty statically about types. See e.g. Sorbet

by cies 5y ago

I find Ruby to be enough of a Smalltalk for my taste. Besides that I see people to stuff with Clojure, such as hot-replacing live code, that I had only seen Smalltalk devs do so far.

disconcision 5y ago

related, see this clojure talk on image-based programming in a functional context: https://www.youtube.com/watch?v=Kgw9fblSOx4 https://www.youtube.com/watch?v=Kgw9fblSOx4

weatherlite 5y ago

So what are the similarities between Ruby and Smalltalk? I'm probably never gonna learn Smalltalk so it's hard to understand what Ruby borrowed.

Mikeb85 5y ago
Everything is an object. Being able to inspect/change running objects, etc...
cies 5y ago
I feel Ruby is mostly another syntax, but the type of OO (with bits of FP where it makes sense in OO) is very much like Smalltalk the language.

0x445442 5y ago

I don't have experience with Ruby or Clojure. While you're debugging an app, can you step to a break point, evaluate the next statement, navigate back up the call stack, change code that's already executed and try again in those languages?

vidarh 5y ago
To an extent. Things like "pry" in Ruby will let you edit methods and reload and resume and generally somewhat pretend you're working on an image. It's not as flexible as a typical Smalltalk environment, but with the new Ruby debugger in Ruby 3.1 I suspect we'll see another big leap towards that.
phyrex 5y ago
Common Lisp lets you do that, but Clojure doesn't - I don't know about Ruby, but I expect not. That said, you have the wrong mental model. You don't run the whole program and set breakpoints. Instead you directly interact with your program-space. Imagine you have a function that retrieves something from an API. So you execute that function and see what it returns. You change that data around a little to fit your usecase, and then hand it off to the function that acts on the API result. That will produce more data; maybe this data is wrong, so you change the function, recompile it and load it into the program space, and try again with the same data you just changed (which is still right there in the variable you defined). Does that make it clearer?

vidarh 5y ago

"pry" in many ways try to borrow even more of Smalltalk into Ruby. E.g. the ability to inspect a running system and bring up an editor to edit a specific method and then load the result into the running system, for example. I often bootstrap experimental code with pry "built in" in various ways, e.g. with a small "prolog" with a few utility methods to hot-reload the code and set up basics to let me keep an editor in one window a pry session in another, make changes and just load the changes without dropping the current state so I can get instant feedback using the test data I already have loaded. For the last two years or so I've used a text editor I wrote in Ruby instead of emacs which spins up a server process on first start that it then exposes via DrB (an IPC library for those not familiar with Ruby) that stores the contents of the buffers and persists them regularly. I did that both so I can implement multiple views on the same buffer without having the same client process keep everything open, and so that if anything crashes I'm unlikely to lose data. But the side effect is that because DrB forwards exceptions too, and the editor itself is set up to catch all exceptions and throw me into pry, if something crashes my editor, I get a pry prompt where I can live-debug it on the real buffers, edit the editor with another instance of itself talking to the same backend server instance, and then hot-replace the code to see if it fixes the bug. For hard-to-reproduce bugs in particular it's amazing to be able to keep the buggy instance running while fixing the problem and figuring out which conditions causes it.

cies 5y ago
I really like this, but I also like strong typing, and somehow it feels I cannot have both. Smalltalk, Ruby, LISPs (Clojure) in one corner A, and Rust, Haskell, OCaml/ReasonML/Rescript, Elm, PureScript in the other corner B. A: quick to "compile", so fast write-run-try loops, very runtime inspectable/updatable, less noisy syntax; but also easier to make runtime errors, larger test suites, less easy to refactor. B: refactorability (especially with good IDE support), strong runtime correctness guarantees; but also long compile times, and no cool runtime inspection/update wizzardry.
- vidarh 5y ago
  Ruby is strongly typed. So is Smalltalk. It is not statically typed, so given a variable you can not know from the variable which type it currently holds. But in Ruby you can always know from the object itself which type it is. That said there's a lot of work going on in Ruby to allow you to get more certainty statically about types. See e.g. Sorbet