5 ms·

There were source code management systems, like ENVY, which made this easy. More than easy, IBM Smalltalk with ENVY was the best system I've ever used for coll

There were source code management systems, like ENVY, which made this easy. More than easy, IBM Smalltalk with ENVY was the best system I've ever used for collaborating with other programmers.

galaxyLogic 4y ago
I used it. It was great especially when you collaborated with other people in the same project who used the same Smalltalk base-image. But things got tricky when different people use different base-images and it is so easy to create new base-images. When you depend on (specific facts about) your base-image you don't need to declare such dependencies anywhere. Combine that with dynamic typing of Smalltalk. Then when you try to move to a different Smalltalk things just don't work and it takes time and effort to figure out why. I guess the way to do it would be to never save your image, but that is so easy and convenient. But if you never save your image, it is as if you are not using the feature of having the "image", so you can't really say it is a good feature if you never use it. When you do image-based development it is hard to control what and how many dependencies you create that are dependencies on the image you are currently working in.
- EdwardCoffin 4y ago
  The way it was handled in my experience was people working on a specific component had someone rebuild the base image they derived their work from periodically, using definite versions of components from other groups. So a group writing one particular part of an application would periodically receive new images containing set versions of infrastructure components and peer applications. Older images would still work of course. Individuals could take those images and substitute specific newer (or older) versions of packages as needed. But definitely groups working on different things mostly only shared things that had been versioned in the shared repository. It seemed to work ok to me.
  - galaxyLogic 4y ago
    It worked, but required extra care and smart team working together. Where I ran into trouble was trying to port an app from one Smalltalk to another. Should be easy right because Smalltalk really is a very simple language. But the ways your code could depend on anything in your image are countless. And no standard language definition with conformance tests. I guess the situation with Smalltalk versions was much like the trouble you have with database vendors today. Or perhaps cloud-providers. Except that Smalltalk was so productive that anybody could easily create their own customizations. In the database world you can write your own views and stored procedures. But you can't modify the base platform on which you must write those things. In Smalltalk it is very easy to modify the platform, and save those modifications in your image. IF you had to declare every class and method you use from the image you wouldn't do so much of it. It would not feel very productive having to declare every dependency. But then, you would have fewer dependencies in the end and your code would be much more portable.
    - igouy 4y ago
      > … required extra care… Compared to which other 1980's language? > … smart team working together. If the team isn't working together the language isn't the problem. > Where I ran into trouble was trying to port an app from one Smalltalk to another. Should be easy right… Compared to porting an app between which other 1980's languages?
      - galaxyLogic 4y ago
        > Compared to porting an app between which other 1980's languages? Say from one C-compiler to another. C is still alive and kicking, Smalltalk not as much as it used to be.
        EdwardCoffin 4y ago
        They aren't really comparable though. C the language was really only comparable with part of Smalltalk, and the parts of Smalltalk it was comparable with were pretty portable. It's the rest of Smalltalk, the operating system interfacing stuff and the like, that C didn't even have. You had to rely on external libraries for that stuff, and they weren't particularly portable. You could write perfectly portable utilities in Smalltalk as long as they didn't rely on any services that were not comparable to what C the language contained within itself.
- igouy 4y ago
  > … tricky when different people use different base-images… Even back in 1984 pre-ENVY the explicit advice was — "At the outset of a project involving two or more programmers: Do assign a member of the team to be the version manager. … The responsibilities of the version manager consist of collecting and cataloging code files submitted by all members of the team, periodically building a new system image incorporating all submitted code files, and releasing the image for use by the team. The version manager stores the current release and all code files for that release in a central place, allowing team members read access, and disallowing write access for anyone except the version manager." (page 500) 1984 "Smalltalk-80 The Interactive Programming Environment" https://rmod-files.lille.inria.fr/FreeBooks/TheInteractiveProgrammingEnv/TheInteractiveProgrammingEnv.pdf https://rmod-files.lille.inria.fr/FreeBooks/TheInteractivePr... > When you depend on (specific facts about) your base-image you don't need to declare such dependencies anywhere. Why would you do what you describe as "image-based" development when you had ENVY/Developer prerequisites "defining exactly which other code an application expects to access"? https://www.google.com/books/edition/Mastering_ENVY_Developer/ld6E19QIMo4C?hl=en&gbpv=1 https://www.google.com/books/edition/Mastering_ENVY_Develope... Wouldn't that be like keeping code in your own personal folder hierarchy when the others were using git?
  - galaxyLogic 4y ago
    > ENVY/Developer prerequisites "defining exactly which other code an application expects to access"? What guarantees such pre-requisites are accurately documented and abided by? Again if you never save or switch the image it can't give you too many problems. But what's the benefit of image-based development then? I think it is like GOTO. You don't need to use GOTO even if your language provides it. But it is a bad idea for a language to provide a GOTO because then many people will use it. and shoot themselves in the foot.
    - 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.

There were source code management systems, like ENVY, which made this easy. More than easy, IBM Smalltalk with ENVY was the best system I've ever used for collaborating with other programmers.

galaxyLogic 4y ago

I used it. It was great especially when you collaborated with other people in the same project who used the same Smalltalk base-image. But things got tricky when different people use different base-images and it is so easy to create new base-images. When you depend on (specific facts about) your base-image you don't need to declare such dependencies anywhere. Combine that with dynamic typing of Smalltalk. Then when you try to move to a different Smalltalk things just don't work and it takes time and effort to figure out why. I guess the way to do it would be to never save your image, but that is so easy and convenient. But if you never save your image, it is as if you are not using the feature of having the "image", so you can't really say it is a good feature if you never use it. When you do image-based development it is hard to control what and how many dependencies you create that are dependencies on the image you are currently working in.

EdwardCoffin 4y ago
The way it was handled in my experience was people working on a specific component had someone rebuild the base image they derived their work from periodically, using definite versions of components from other groups. So a group writing one particular part of an application would periodically receive new images containing set versions of infrastructure components and peer applications. Older images would still work of course. Individuals could take those images and substitute specific newer (or older) versions of packages as needed. But definitely groups working on different things mostly only shared things that had been versioned in the shared repository. It seemed to work ok to me.
- galaxyLogic 4y ago
  It worked, but required extra care and smart team working together. Where I ran into trouble was trying to port an app from one Smalltalk to another. Should be easy right because Smalltalk really is a very simple language. But the ways your code could depend on anything in your image are countless. And no standard language definition with conformance tests. I guess the situation with Smalltalk versions was much like the trouble you have with database vendors today. Or perhaps cloud-providers. Except that Smalltalk was so productive that anybody could easily create their own customizations. In the database world you can write your own views and stored procedures. But you can't modify the base platform on which you must write those things. In Smalltalk it is very easy to modify the platform, and save those modifications in your image. IF you had to declare every class and method you use from the image you wouldn't do so much of it. It would not feel very productive having to declare every dependency. But then, you would have fewer dependencies in the end and your code would be much more portable.
  - igouy 4y ago
    > … required extra care… Compared to which other 1980's language? > … smart team working together. If the team isn't working together the language isn't the problem. > Where I ran into trouble was trying to port an app from one Smalltalk to another. Should be easy right… Compared to porting an app between which other 1980's languages?
    - galaxyLogic 4y ago
      > Compared to porting an app between which other 1980's languages? Say from one C-compiler to another. C is still alive and kicking, Smalltalk not as much as it used to be.
      - EdwardCoffin 4y ago
        They aren't really comparable though. C the language was really only comparable with part of Smalltalk, and the parts of Smalltalk it was comparable with were pretty portable. It's the rest of Smalltalk, the operating system interfacing stuff and the like, that C didn't even have. You had to rely on external libraries for that stuff, and they weren't particularly portable. You could write perfectly portable utilities in Smalltalk as long as they didn't rely on any services that were not comparable to what C the language contained within itself.
igouy 4y ago
> … tricky when different people use different base-images… Even back in 1984 pre-ENVY the explicit advice was — "At the outset of a project involving two or more programmers: Do assign a member of the team to be the version manager. … The responsibilities of the version manager consist of collecting and cataloging code files submitted by all members of the team, periodically building a new system image incorporating all submitted code files, and releasing the image for use by the team. The version manager stores the current release and all code files for that release in a central place, allowing team members read access, and disallowing write access for anyone except the version manager." (page 500) 1984 "Smalltalk-80 The Interactive Programming Environment" https://rmod-files.lille.inria.fr/FreeBooks/TheInteractiveProgrammingEnv/TheInteractiveProgrammingEnv.pdf https://rmod-files.lille.inria.fr/FreeBooks/TheInteractivePr... > When you depend on (specific facts about) your base-image you don't need to declare such dependencies anywhere. Why would you do what you describe as "image-based" development when you had ENVY/Developer prerequisites "defining exactly which other code an application expects to access"? https://www.google.com/books/edition/Mastering_ENVY_Developer/ld6E19QIMo4C?hl=en&gbpv=1 https://www.google.com/books/edition/Mastering_ENVY_Develope... Wouldn't that be like keeping code in your own personal folder hierarchy when the others were using git?
- galaxyLogic 4y ago
  > ENVY/Developer prerequisites "defining exactly which other code an application expects to access"? What guarantees such pre-requisites are accurately documented and abided by? Again if you never save or switch the image it can't give you too many problems. But what's the benefit of image-based development then? I think it is like GOTO. You don't need to use GOTO even if your language provides it. But it is a bad idea for a language to provide a GOTO because then many people will use it. and shoot themselves in the foot.
  - 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.