4 ms·

That image environment sounds scary to me. I used to do a lot of hardware development, and what I love most about software is that you can always restart from t

by theamk 9y ago

That image environment sounds scary to me. I used to do a lot of hardware development, and what I love most about software is that you can always restart from the clean plate (by restarting the program) and/or undo your previous work (with version control). From what I understand, none of this applies to Smalltalk. You always modify code on the fly, so you may end up with properties which exists, but no current code ever sets them. Or your program ends up in the invalid state, and you have no idea why -- is it a genuine bug or did it happen few minutes ago, when the function was still incomplete?

igouy 9y ago
Simply a) keep a copy of the original image [clean slate] b) keep a copy of your changes/additions [use version control if you like] c) import b into a. Repeat daily or weekly as you please. > You always modify code on the fly Since back in the '70s when Smalltalk was being created at Xerox PARC and used there for experimental systems development, changes were automagically recorded in a changes .cha text file. For more information on the primitive techniques from back in those days see -- "Managing the Evolution of Smalltalk-80 Systems" in Smalltalk-80: Bits of History, Words of Advice http://sdmeta.gforge.inria.fr/FreeBooks/BitsOfHistory/BitsOfHistory.pdf http://sdmeta.gforge.inria.fr/FreeBooks/BitsOfHistory/BitsOf...
- otabdeveloper1 9y ago
  > Simply a) keep a copy of the original image [clean slate] b) keep a copy of your changes/additions [version control] c) import b into a. Really? So we're back to "MyImage.img.bak.2.old.works", "MyImage.img.bak.3.works", "MyImage.img.bak.2.test"? Now that is an experience I do not want to ever have to experience again.
  - igouy 9y ago
    > So we're back to… No, that's a bizarre suggestion you just invented, it has nothing to do with what I wrote.
  - vajrabum 9y ago
    No you don't manage and back up using images (you can of course). Instead you manage and back up diffs just like you would in any other language. You can do that from inside or outside the VM. From the outside, the VM writes it's changes to a change (diff or journal) file and you get to choose when and if you're going to commit those changes. You can use that file to make commits to your SCM.
  - ben-coman 9y ago
    The development workflow for Pharo is that every code change has a CI performs a bootstrap build of the whole system pulled from a git repository. Then your CI adds your production code on top of that. So it doesn't get lost in the mass of other comments, here again is some info on Pharo's bootstrap process... http://www.esug.org/data/ESUG2016/04-Thursday/1000-1030%20Mission%20Pharo%20Kernel/2016-08-25-Mission-Pharo-Bootstrap-ESUG-2016.pdf http://www.esug.org/data/ESUG2016/04-Thursday/1000-1030%20Mi...
stcredzero 9y ago
what I love most about software is that you can always restart from the clean plate (by restarting the program) and/or undo your previous work (with version control). That's what I loved best about Smalltalk. You could just hard quit out of the image, then go back to the Change Log and replay all but the last few changes. If you save off an image every day or so, you're always back in minutes, no matter how dangerously you've been coding. There are a variety of utilities which let you load code quickly. Most often, deployment was done using one of these loading onto a clean or a stripped image. You can certainly control changes to your environment. In fact, I'd say you can often control them more easily than in other environments. you have no idea why -- is it a genuine bug or did it happen few minutes ago, when the function was still incomplete? The Change Log makes it very easy to figure that out. All of your ad-hoc "command-line" (do-it) state changes to the image are recorded there as well.
- 0x445442 9y ago
  This is a great insight but when I read things like this it reminds me the Smalltalk advocates need to do a better job adressing the concerns of the broader development community. It seems like they spend too much time addressing things that aren't concerns and not enough time on things that are.
radiowave 9y ago
That can happen, but typically you're not keeping state around for huge periods of time (though you can if you want), it's just a convenience while you rapidly iterate on the design of the code. Once you've got code that seems to hang together well, it's time to start thinking about what the right way to instantiate the objects, to consistently bring them to a correct state. Unit tests are useful for this, and with a brief (ab)use of a global variable, you can often make the tests run against your hand-made object, and verify that the test results are the same as when testing a properly instantiated object. After that you can dispense with your hand-made instance. Somewhat related, you can use unit tests of as-yet unimplemented functionality as a jumping-off point for live-coding your way towards the right implementation, with the debugger acting as a combined code editor and REPL (since the formal parameter names in the code will have real, evaluatable values behind them - as supplied by the test case). Were I a major Test Driven Development adherent, I might claim that this is the non-cargo-cult way of doing TDD.
- ScottBurson 9y ago
  All this works perfectly well in Common Lisp too.
ben-coman 9y ago
You may be interested in the bootstrap work Pharo has been doing... http://www.esug.org/data/ESUG2016/04-Thursday/1000-1030%20Mission%20Pharo%20Kernel/2016-08-25-Mission-Pharo-Bootstrap-ESUG-2016.pdf http://www.esug.org/data/ESUG2016/04-Thursday/1000-1030%20Mi...

by theamk 9y ago

igouy 9y ago

Simply a) keep a copy of the original image [clean slate] b) keep a copy of your changes/additions [use version control if you like] c) import b into a. Repeat daily or weekly as you please. > You always modify code on the fly Since back in the '70s when Smalltalk was being created at Xerox PARC and used there for experimental systems development, changes were automagically recorded in a changes .cha text file. For more information on the primitive techniques from back in those days see -- "Managing the Evolution of Smalltalk-80 Systems" in Smalltalk-80: Bits of History, Words of Advice http://sdmeta.gforge.inria.fr/FreeBooks/BitsOfHistory/BitsOfHistory.pdf http://sdmeta.gforge.inria.fr/FreeBooks/BitsOfHistory/BitsOf...

otabdeveloper1 9y ago
> Simply a) keep a copy of the original image [clean slate] b) keep a copy of your changes/additions [version control] c) import b into a. Really? So we're back to "MyImage.img.bak.2.old.works", "MyImage.img.bak.3.works", "MyImage.img.bak.2.test"? Now that is an experience I do not want to ever have to experience again.
- igouy 9y ago
  > So we're back to… No, that's a bizarre suggestion you just invented, it has nothing to do with what I wrote.
- vajrabum 9y ago
  No you don't manage and back up using images (you can of course). Instead you manage and back up diffs just like you would in any other language. You can do that from inside or outside the VM. From the outside, the VM writes it's changes to a change (diff or journal) file and you get to choose when and if you're going to commit those changes. You can use that file to make commits to your SCM.
- ben-coman 9y ago
  The development workflow for Pharo is that every code change has a CI performs a bootstrap build of the whole system pulled from a git repository. Then your CI adds your production code on top of that. So it doesn't get lost in the mass of other comments, here again is some info on Pharo's bootstrap process... http://www.esug.org/data/ESUG2016/04-Thursday/1000-1030%20Mission%20Pharo%20Kernel/2016-08-25-Mission-Pharo-Bootstrap-ESUG-2016.pdf http://www.esug.org/data/ESUG2016/04-Thursday/1000-1030%20Mi...

stcredzero 9y ago

what I love most about software is that you can always restart from the clean plate (by restarting the program) and/or undo your previous work (with version control). That's what I loved best about Smalltalk. You could just hard quit out of the image, then go back to the Change Log and replay all but the last few changes. If you save off an image every day or so, you're always back in minutes, no matter how dangerously you've been coding. There are a variety of utilities which let you load code quickly. Most often, deployment was done using one of these loading onto a clean or a stripped image. You can certainly control changes to your environment. In fact, I'd say you can often control them more easily than in other environments. you have no idea why -- is it a genuine bug or did it happen few minutes ago, when the function was still incomplete? The Change Log makes it very easy to figure that out. All of your ad-hoc "command-line" (do-it) state changes to the image are recorded there as well.

0x445442 9y ago
This is a great insight but when I read things like this it reminds me the Smalltalk advocates need to do a better job adressing the concerns of the broader development community. It seems like they spend too much time addressing things that aren't concerns and not enough time on things that are.

radiowave 9y ago

That can happen, but typically you're not keeping state around for huge periods of time (though you can if you want), it's just a convenience while you rapidly iterate on the design of the code. Once you've got code that seems to hang together well, it's time to start thinking about what the right way to instantiate the objects, to consistently bring them to a correct state. Unit tests are useful for this, and with a brief (ab)use of a global variable, you can often make the tests run against your hand-made object, and verify that the test results are the same as when testing a properly instantiated object. After that you can dispense with your hand-made instance. Somewhat related, you can use unit tests of as-yet unimplemented functionality as a jumping-off point for live-coding your way towards the right implementation, with the debugger acting as a combined code editor and REPL (since the formal parameter names in the code will have real, evaluatable values behind them - as supplied by the test case). Were I a major Test Driven Development adherent, I might claim that this is the non-cargo-cult way of doing TDD.

ScottBurson 9y ago
All this works perfectly well in Common Lisp too.

ben-coman 9y ago

You may be interested in the bootstrap work Pharo has been doing... http://www.esug.org/data/ESUG2016/04-Thursday/1000-1030%20Mission%20Pharo%20Kernel/2016-08-25-Mission-Pharo-Bootstrap-ESUG-2016.pdf http://www.esug.org/data/ESUG2016/04-Thursday/1000-1030%20Mi...