4 ms·

Edit: Thinking about it, I realise it's actually a lot closer to Smalltalk than to Lisp -- you have a built in editor, you build memory images that you constan

Edit: Thinking about it, I realise it's actually a lot closer to Smalltalk than to Lisp -- you have a built in editor, you build memory images that you constantly work with, all the code is decompilable so you can refactor easily, etc, etc Actual edit: you'd think I could find the edit button :-P

TeMPOraL 9y ago
I guess Lisp was like that in the good days of Lisp machines. Nowadays, all that remained is "you build memory images that you constantly work with", and Emacs, which is merely a shadow of the old stuff (but still beyond awesome).
lispm 9y ago
Smalltalk does not decompile code (though one can with some limits), but works with an integrated code management. Interlisp-D also did that.
- jecel 9y ago
  Actually, a bytecode to text decompiler is a very important part of the typical Smalltalk IDE. In Squeak or Pharo, for example, you give the virtual machine a binary file like "work.image" to start the system and it looks for text files "work.changes" and "version4.sources" so the code browser can show you the sources. If these extra files are missing it will complain, but will continue to work normally. If you pay attention you will notice that the sources have no comments and all local variables are called t2 or t5 - that is the decompiler subtly doing its job.
  - lispm 9y ago
    How is that 'important'? Usually one writes sources. And that's what is maintained by the Smalltalk development environment. Since Smalltalk usually comes with the system sources there is also no need to decompile the bytecode. OTOH some Lisps keep the s-expressions in the image and can run them directly via a Lisp interpreter.
  - mikekchar 9y ago
    Yeah, what I was thinking of was that the ability to create an AST from the running image is how the refactoring browser works. I'm not really aware of any Forth analogy, but it's fairly common (in my limited experience) for Forth programmers to hack away in the repl, decompile what they've done and then bung it in the block editor -- so it's kind of a manual version of the same thing. I really wasn't trying to make any profound statement. Just noting something that looked kind of similar :-)
kbp 9y ago
> I realise it's actually a lot closer to Smalltalk than to Lisp -- you have a built in editor, you build memory images that you constantly work with, all the code is decompilable so you can refactor easily, etc, etc Lisps often provide built in editors; Common Lisp even has the standard function ED for invoking one[0], but like most of the "environment" functions its behaviour is left almost entirely unspecified. Lisp is also usually developed in an image-based fashion. Images are one of the features that separate Lisp and Smalltalk from almost everything else, not one that separates them from each other. Some Lisps provide access to source code from function objects, with varying degrees of integration, and again, Common Lisp provides the standard function FUNCTION-LAMBDA-EXPRESSION for this purpose[1]. They don't generally work via decompilation, but neither does Smalltalk. 0: http://www.lispworks.com/documentation/HyperSpec/Body/f_ed.htm http://www.lispworks.com/documentation/HyperSpec/Body/f_ed.h... 1: http://www.lispworks.com/documentation/HyperSpec/Body/f_fn_lam.htm http://www.lispworks.com/documentation/HyperSpec/Body/f_fn_l...

TeMPOraL 9y ago

I guess Lisp was like that in the good days of Lisp machines. Nowadays, all that remained is "you build memory images that you constantly work with", and Emacs, which is merely a shadow of the old stuff (but still beyond awesome).

lispm 9y ago

Smalltalk does not decompile code (though one can with some limits), but works with an integrated code management. Interlisp-D also did that.

jecel 9y ago
Actually, a bytecode to text decompiler is a very important part of the typical Smalltalk IDE. In Squeak or Pharo, for example, you give the virtual machine a binary file like "work.image" to start the system and it looks for text files "work.changes" and "version4.sources" so the code browser can show you the sources. If these extra files are missing it will complain, but will continue to work normally. If you pay attention you will notice that the sources have no comments and all local variables are called t2 or t5 - that is the decompiler subtly doing its job.
- lispm 9y ago
  How is that 'important'? Usually one writes sources. And that's what is maintained by the Smalltalk development environment. Since Smalltalk usually comes with the system sources there is also no need to decompile the bytecode. OTOH some Lisps keep the s-expressions in the image and can run them directly via a Lisp interpreter.
- mikekchar 9y ago
  Yeah, what I was thinking of was that the ability to create an AST from the running image is how the refactoring browser works. I'm not really aware of any Forth analogy, but it's fairly common (in my limited experience) for Forth programmers to hack away in the repl, decompile what they've done and then bung it in the block editor -- so it's kind of a manual version of the same thing. I really wasn't trying to make any profound statement. Just noting something that looked kind of similar :-)

kbp 9y ago

> I realise it's actually a lot closer to Smalltalk than to Lisp -- you have a built in editor, you build memory images that you constantly work with, all the code is decompilable so you can refactor easily, etc, etc Lisps often provide built in editors; Common Lisp even has the standard function ED for invoking one[0], but like most of the "environment" functions its behaviour is left almost entirely unspecified. Lisp is also usually developed in an image-based fashion. Images are one of the features that separate Lisp and Smalltalk from almost everything else, not one that separates them from each other. Some Lisps provide access to source code from function objects, with varying degrees of integration, and again, Common Lisp provides the standard function FUNCTION-LAMBDA-EXPRESSION for this purpose[1]. They don't generally work via decompilation, but neither does Smalltalk. 0: http://www.lispworks.com/documentation/HyperSpec/Body/f_ed.htm http://www.lispworks.com/documentation/HyperSpec/Body/f_ed.h... 1: http://www.lispworks.com/documentation/HyperSpec/Body/f_fn_lam.htm http://www.lispworks.com/documentation/HyperSpec/Body/f_fn_l...