3 ms·

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,

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
      Wouldn't "trying to port an app" mean trying to port between different C gui libraries? (Just like "trying to port an app from one Smalltalk to another" would mean trying to port between different Smalltalk gui libraries.)

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
    Wouldn't "trying to port an app" mean trying to port between different C gui libraries? (Just like "trying to port an app from one Smalltalk to another" would mean trying to port between different Smalltalk gui libraries.)