4 ms·

I had my mind lightly blown watching someone using Squeak Smalltalk to interactively prototype something or other. They purposefully called a method which did

I had my mind lightly blown watching someone using Squeak Smalltalk to interactively prototype something or other. They purposefully called a method which did NOT exist, used the debugger to partially unwind the #doesNotUnderstand stack, implemented the method, which then returned the expected result as if the method had existed all along. Benefits of super late binding I guess.

ssivark 6y ago
This is like the best case example of test driven development. I don’t understand what is stopping other languages from supporting “live debugging” of this kind.
- Jtsummers 6y ago
  Whether or not they can support patching changes into a live system. You can get really good debuggers but lacking that capability you won't approach what Smalltalk and Common Lisp offer. And if it's non-standard (say you do implement it for C with a specific compiler and debugger, but no one else does it or all do it a different way) then you won't win any mindshare outside of that target platform.
  - ssivark 6y ago
    To dig a little deeper, what impedes a runtime from supporting live patching? Why doesn’t Python have this, for example?
  - oweqruiowe 6y ago
    Clojure user here, and I often don't know the details behind this, can you explain? When trying to explain the repl it's. easy for folks to say "okay, don't I have that too?" but yea, really the updating of values from your editor into this running application 'universe' seems like it should just work for every language, so what is special about lisp that enables it?
    - Jtsummers 6y ago
      It's possible to do with probably every language out there, it's just not always as practical. Common Lisp, Erlang, and other languages were (in part) designed around interactivity with the running system. In many ways, at execution time, programs in those languages are actually running on a separate operating system hosted by your main OS. This environment is tailored specifically to monitoring, updating, and extending the running program. Compared to C, which has no such infrastructure baked in. At run time, it is whatever you told it to be at compile time (modulo dynamic libraries that may have been loaded). To manipulate C programs at runtime you have to attach a debugger, which does let you do quite a bit. But you're also stepping outside the C language to do it. Versus Common Lisp, Clojure, Erlang, Elixir, and others which present an interface to the running system that is the same (or very nearly the same) as the language itself, and even permits definition of new functions within that interface (you aren't going to write a C function in a C debugger and load it in place of another C function in your running program).
veddox 6y ago
Sounds cool, but what exactly is the advantage of doing it like that?
- Jtsummers 6y ago
  There are a couple reasons and ways to use that approach. Unlike batch compiled languages, Smalltalk and Common Lisp (and some others) will throw an exception/signal an error/whatever that indicates that a function doesn't exist. This means that you can insert these calls and, unless they actually occur, the rest of your program runs just fine. In most batch compiled languages you'd at least need to insert a dummy method/function (in C# you'll see NotImplementedException being thrown in these). When you encounter the exception, in languages that support it, you can write the code at that time and then let the system resume, or tell the debugger to return a value. Maybe you don't know how to implement that function, but you know the kind of thing it should return and, for some reason, you don't want to leave function floating out there that just returns a dummy value permanently ((defun random () 4))). If you use a language like Smalltalk, there's also a tendency to write very short methods. You could use this approach to create your program in a more top-down fashion (versus bottom-up) by doing something like this (I don't know Smalltalk so this is lisp): (defun main() (factorial 10)) Debugger is brought up because factorial doesn't exist. (defun factorial (n) (fact-aux n 1)) ;; not really needed in Common Lisp, but just to illustrate Again the debugger is brought up so we define the next function: (defun fact-aux (n acc) (if (<= n 0) acc (fact-aux (1- n) (* n acc))) If you already have a design in mind (sketched out on paper perhaps), you could use something like this pretty effectively. Not sure I would though.
- vindarel 6y ago
  You can write tests and then the functions: https://www.youtube.com/watch?v=CNFr7zIfyeM https://www.youtube.com/watch?v=CNFr7zIfyeM and you can interactively fix failing tests: https://peertube.video/videos/watch/c0c82209-feaa-444d-962f-afa25745bfc0 https://peertube.video/videos/watch/c0c82209-feaa-444d-962f-...

ssivark 6y ago

This is like the best case example of test driven development. I don’t understand what is stopping other languages from supporting “live debugging” of this kind.

Jtsummers 6y ago
Whether or not they can support patching changes into a live system. You can get really good debuggers but lacking that capability you won't approach what Smalltalk and Common Lisp offer. And if it's non-standard (say you do implement it for C with a specific compiler and debugger, but no one else does it or all do it a different way) then you won't win any mindshare outside of that target platform.
- ssivark 6y ago
  To dig a little deeper, what impedes a runtime from supporting live patching? Why doesn’t Python have this, for example?
- oweqruiowe 6y ago
  Clojure user here, and I often don't know the details behind this, can you explain? When trying to explain the repl it's. easy for folks to say "okay, don't I have that too?" but yea, really the updating of values from your editor into this running application 'universe' seems like it should just work for every language, so what is special about lisp that enables it?
  - Jtsummers 6y ago
    It's possible to do with probably every language out there, it's just not always as practical. Common Lisp, Erlang, and other languages were (in part) designed around interactivity with the running system. In many ways, at execution time, programs in those languages are actually running on a separate operating system hosted by your main OS. This environment is tailored specifically to monitoring, updating, and extending the running program. Compared to C, which has no such infrastructure baked in. At run time, it is whatever you told it to be at compile time (modulo dynamic libraries that may have been loaded). To manipulate C programs at runtime you have to attach a debugger, which does let you do quite a bit. But you're also stepping outside the C language to do it. Versus Common Lisp, Clojure, Erlang, Elixir, and others which present an interface to the running system that is the same (or very nearly the same) as the language itself, and even permits definition of new functions within that interface (you aren't going to write a C function in a C debugger and load it in place of another C function in your running program).

veddox 6y ago

Sounds cool, but what exactly is the advantage of doing it like that?

Jtsummers 6y ago
There are a couple reasons and ways to use that approach. Unlike batch compiled languages, Smalltalk and Common Lisp (and some others) will throw an exception/signal an error/whatever that indicates that a function doesn't exist. This means that you can insert these calls and, unless they actually occur, the rest of your program runs just fine. In most batch compiled languages you'd at least need to insert a dummy method/function (in C# you'll see NotImplementedException being thrown in these). When you encounter the exception, in languages that support it, you can write the code at that time and then let the system resume, or tell the debugger to return a value. Maybe you don't know how to implement that function, but you know the kind of thing it should return and, for some reason, you don't want to leave function floating out there that just returns a dummy value permanently ((defun random () 4))). If you use a language like Smalltalk, there's also a tendency to write very short methods. You could use this approach to create your program in a more top-down fashion (versus bottom-up) by doing something like this (I don't know Smalltalk so this is lisp): (defun main() (factorial 10)) Debugger is brought up because factorial doesn't exist. (defun factorial (n) (fact-aux n 1)) ;; not really needed in Common Lisp, but just to illustrate Again the debugger is brought up so we define the next function: (defun fact-aux (n acc) (if (<= n 0) acc (fact-aux (1- n) (* n acc))) If you already have a design in mind (sketched out on paper perhaps), you could use something like this pretty effectively. Not sure I would though.
vindarel 6y ago
You can write tests and then the functions: https://www.youtube.com/watch?v=CNFr7zIfyeM https://www.youtube.com/watch?v=CNFr7zIfyeM and you can interactively fix failing tests: https://peertube.video/videos/watch/c0c82209-feaa-444d-962f-afa25745bfc0 https://peertube.video/videos/watch/c0c82209-feaa-444d-962f-...