4 ms·

I taught myself Smalltalk in 1988 coming from Modula-2. It's simply anachronistic to judge Smalltalk implementations of that past decade against version contro

by igouy 5y ago

I taught myself Smalltalk in 1988 coming from Modula-2. It's simply anachronistic to judge Smalltalk implementations of that past decade against version control of this decade, when there have been newer Smalltalk implementations with version control. Even back in 1983 the blue book discussed "Storing the set of Changes on a File" (page 465) and "Commands that check for conflicts" ( http://rmod-files.lille.inria.fr/FreeBooks/TheInteractiveProgrammingEnv/TheInteractiveProgrammingEnv.pdf http://rmod-files.lille.inria.fr/FreeBooks/TheInteractivePro... page 472). "Whether your development team consists of one person, or many: Do understand and use the change manager. The change manager is one of the most important tools for software development in the Smalltalk-80 environment. … It allows you to selectively browse [changes], remove [changes] incorporate them into another version of the system, check for conflicts, and prepare the changes for release to other members of the development team or to end users." (page 500 "Smalltalk-80 Software Development Do's and Dont's") > Your image persists your data and changes forever—including any mistakes you make… Even back in 1988, source code changes made with the Smalltalk IDE were automatically logged to a text file (the change log) and we could choose which of the logged source code changes to apply later to an unchanged image file. So no, mistakes were not forever.

smackeyacky 5y ago
I don't know about that. For most of the VisualWorks programmers I was tasked with helping in the 1990s, the change log was an error prone way of sharing changes amongst your team members - this was before ParcPlace implemented packages properly and whatnot. All of it was pretty useless compared to using Envy/Developer which was a unique version control system that was based entirely around Smalltalk and collected up your changes in a way that made sense for sharing. The guys at ParcPlace never seemed to quite understand what we were facing back then - your average departmental programmer trying to replace a green screen in a team of 20 other programmers not only had to cope with a complete change of paradigm for the programming language, but the version control systems were non-existent or useless even compared with simple systems like SCCS. Change logs just didn't cut it when you got past 2 developers. The vanilla VisualWorks simply didn't scale to multiple users trying to share code. Envy/Developer fixed that (and how! Still the best version control system I have ever used). The "forever" thing might be an exaggeration, but in practical terms I had a lot of guys destroy images accidentally by over-ridding something in Object or whatever while they were learning and causing havoc for themselves. Trying to piece together their good work from the change log was...effectively impossible until they learned what they were doing due to the total scattergun approach a lot of them used. So perhaps not "forever", but given the time constraints in a normal development environment, it was forever for certain values of forever.
- igouy 5y ago
  > … effectively impossible until they learned what they were doing due to the total scattergun approach a lot of them used. You tell us the people didn't know what they were doing — so why blame the tools? (Incidentally, I used Envy/Developer for years.)
  - smackeyacky 5y ago
    I blame the tools because they were inadequate at the time and inferior to even rudimentary things like sccs. Not every programmer is a superstar. Visual basic was a much better environment for average guys doing green screen replacement jobs.
    - igouy 5y ago
      > … replace a green screen in a team of 20 other programmers… I was briefly involved with a project that sounds a bit like that — a 2 week training course for current staff, then rewrite everything from data model to U/X in half-the-usual time because someone said OO is more productive. That project used ENVY/Developer. The staff admin deleted the repo. The staff wouldn't have passed phone screen for Smalltalk work (maybe some would have in 6 or 12 months). When the people don't know the basic tools, that's what matters.
      - smackeyacky 5y ago
        It does help if they know the tools. The main struggle we had wasn't that they weren't smart, most of them were fantastic domain experts who just didn't have that inquisitive tech spark that sets different breeds of IT people apart. There is nothing wrong with being a domain expert who isn't that keen on cutting edge tools, but back then giving them smalltalk was a mistake. VB and powerbuilder were theoretically inferior, but far more productive for guys like that.
- igouy 5y ago
  > … didn't scale to multiple users trying to share code… Just curious, what process did you tell them to get past their "scattergun approach"? I never looked at the 1984 "Smalltalk-80 The Interactive Programming Environment" book until about a year ago, so very much with the benefit of hindsight — "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) http://rmod-files.lille.inria.fr/FreeBooks/TheInteractiveProgrammingEnv/TheInteractiveProgrammingEnv.pdf http://rmod-files.lille.inria.fr/FreeBooks/TheInteractivePro...

by igouy 5y ago

smackeyacky 5y ago

I don't know about that. For most of the VisualWorks programmers I was tasked with helping in the 1990s, the change log was an error prone way of sharing changes amongst your team members - this was before ParcPlace implemented packages properly and whatnot. All of it was pretty useless compared to using Envy/Developer which was a unique version control system that was based entirely around Smalltalk and collected up your changes in a way that made sense for sharing. The guys at ParcPlace never seemed to quite understand what we were facing back then - your average departmental programmer trying to replace a green screen in a team of 20 other programmers not only had to cope with a complete change of paradigm for the programming language, but the version control systems were non-existent or useless even compared with simple systems like SCCS. Change logs just didn't cut it when you got past 2 developers. The vanilla VisualWorks simply didn't scale to multiple users trying to share code. Envy/Developer fixed that (and how! Still the best version control system I have ever used). The "forever" thing might be an exaggeration, but in practical terms I had a lot of guys destroy images accidentally by over-ridding something in Object or whatever while they were learning and causing havoc for themselves. Trying to piece together their good work from the change log was...effectively impossible until they learned what they were doing due to the total scattergun approach a lot of them used. So perhaps not "forever", but given the time constraints in a normal development environment, it was forever for certain values of forever.

igouy 5y ago
> … effectively impossible until they learned what they were doing due to the total scattergun approach a lot of them used. You tell us the people didn't know what they were doing — so why blame the tools? (Incidentally, I used Envy/Developer for years.)
- smackeyacky 5y ago
  I blame the tools because they were inadequate at the time and inferior to even rudimentary things like sccs. Not every programmer is a superstar. Visual basic was a much better environment for average guys doing green screen replacement jobs.
  - igouy 5y ago
    > … replace a green screen in a team of 20 other programmers… I was briefly involved with a project that sounds a bit like that — a 2 week training course for current staff, then rewrite everything from data model to U/X in half-the-usual time because someone said OO is more productive. That project used ENVY/Developer. The staff admin deleted the repo. The staff wouldn't have passed phone screen for Smalltalk work (maybe some would have in 6 or 12 months). When the people don't know the basic tools, that's what matters.
    - smackeyacky 5y ago
      It does help if they know the tools. The main struggle we had wasn't that they weren't smart, most of them were fantastic domain experts who just didn't have that inquisitive tech spark that sets different breeds of IT people apart. There is nothing wrong with being a domain expert who isn't that keen on cutting edge tools, but back then giving them smalltalk was a mistake. VB and powerbuilder were theoretically inferior, but far more productive for guys like that.
igouy 5y ago
> … didn't scale to multiple users trying to share code… Just curious, what process did you tell them to get past their "scattergun approach"? I never looked at the 1984 "Smalltalk-80 The Interactive Programming Environment" book until about a year ago, so very much with the benefit of hindsight — "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) http://rmod-files.lille.inria.fr/FreeBooks/TheInteractiveProgrammingEnv/TheInteractiveProgrammingEnv.pdf http://rmod-files.lille.inria.fr/FreeBooks/TheInteractivePro...