4 ms·

What guarantees code is in the project git repo and not scattered across strangely named files and folders on someone’s personal hard-drive? Remember when you

by igouy 4y ago

What guarantees code is in the project git repo and not scattered across strangely named files and folders on someone’s personal hard-drive? Remember when you used ENVY? You could save the image. You could come back next day and pickup your work where you stopped. Even though all the methods were versioned and shared.

galaxyLogic 4y ago
Having an 'image' has its pros and cons. I'm not saying it's all bad. It is very convenient for the day-to-day programming. Change something in the image, save it and come back the next day. What could be more convenient. I'm saying that using an image and relying on it, having undeclared dependencies on it, saving it and versioning the image has an adverse effect on the long term maintainability and integrability of the software. Say you had your source-code neatly stored and organized in Envy. Then could you just give your Envy-stored source to some developer in the field-office or an open-source collaborator around the world and say: Use this source-code to develop this further? Probably not. You would ALSO have to say by the way you must use this particular version of the base-image. Right? And then, when there are several divergent base-images for different projects, how do you merge those base-images? Envy is the cure to the problem that is reliance on the image. Then you say it is great. Yes because of Envy. Not because of the "image".
- igouy 4y ago
  > … some developer in the field-office… Incidentally multi-site development (page 89) and remote work (page 312) are discussed in "Mastering ENVY/Developer" but here's the part of your comment that puzzles me: you write this as-if it's some-kind-of gotcha? > You would ALSO have to say by the way you must use this particular version of the base-image. Right? To make the build process reproducible we start with the same thing and then add, remove and change stuff. Right? That wasn't because of ENVY. That was something that would be written as a Smalltalk script — because reproducible.
- igouy 4y ago
  > I'm saying that using an image and relying on it, having undeclared dependencies on it, saving it and versioning the image has an adverse effect on … What exactly do you mean by "having undeclared dependencies" ? Doesn't the changes file show everything that's been changed, added or removed? "Within each project, a set of changes you make to class descriptions is maintained. … Using a browser view of this set of changes, you can find out what you have been doing. Also, you can use the set of changes to create an external file containing descriptions of the modifications you have made to the system so that you can share your work with other users. … The storage of changes in the Smalltalk-80 system takes two forms: an internal form as a set of changes (actually a set of objects describing changes), and an external form as a file on which your actions are logged while you are working (in the form of executable expressions or expressions that can be filed into a system). … All the information stored in the internal change set is also written onto the changes file." 1984 Smalltalk-80 The Interactive Programming Environment page 461 https://rmod-files.lille.inria.fr/FreeBooks/TheInteractiveProgrammingEnv/TheInteractiveProgrammingEnv.pdf https://rmod-files.lille.inria.fr/FreeBooks/TheInteractivePr...

by igouy 4y ago

galaxyLogic 4y ago

Having an 'image' has its pros and cons. I'm not saying it's all bad. It is very convenient for the day-to-day programming. Change something in the image, save it and come back the next day. What could be more convenient. I'm saying that using an image and relying on it, having undeclared dependencies on it, saving it and versioning the image has an adverse effect on the long term maintainability and integrability of the software. Say you had your source-code neatly stored and organized in Envy. Then could you just give your Envy-stored source to some developer in the field-office or an open-source collaborator around the world and say: Use this source-code to develop this further? Probably not. You would ALSO have to say by the way you must use this particular version of the base-image. Right? And then, when there are several divergent base-images for different projects, how do you merge those base-images? Envy is the cure to the problem that is reliance on the image. Then you say it is great. Yes because of Envy. Not because of the "image".

igouy 4y ago
> … some developer in the field-office… Incidentally multi-site development (page 89) and remote work (page 312) are discussed in "Mastering ENVY/Developer" but here's the part of your comment that puzzles me: you write this as-if it's some-kind-of gotcha? > You would ALSO have to say by the way you must use this particular version of the base-image. Right? To make the build process reproducible we start with the same thing and then add, remove and change stuff. Right? That wasn't because of ENVY. That was something that would be written as a Smalltalk script — because reproducible.
igouy 4y ago
> I'm saying that using an image and relying on it, having undeclared dependencies on it, saving it and versioning the image has an adverse effect on … What exactly do you mean by "having undeclared dependencies" ? Doesn't the changes file show everything that's been changed, added or removed? "Within each project, a set of changes you make to class descriptions is maintained. … Using a browser view of this set of changes, you can find out what you have been doing. Also, you can use the set of changes to create an external file containing descriptions of the modifications you have made to the system so that you can share your work with other users. … The storage of changes in the Smalltalk-80 system takes two forms: an internal form as a set of changes (actually a set of objects describing changes), and an external form as a file on which your actions are logged while you are working (in the form of executable expressions or expressions that can be filed into a system). … All the information stored in the internal change set is also written onto the changes file." 1984 Smalltalk-80 The Interactive Programming Environment page 461 https://rmod-files.lille.inria.fr/FreeBooks/TheInteractiveProgrammingEnv/TheInteractiveProgrammingEnv.pdf https://rmod-files.lille.inria.fr/FreeBooks/TheInteractivePr...