3 ms·

Lisp and Smalltalk failed because it was near impossible to share the code. Living images are really hard to merge. Smallltalk did eventually get a fantastic

Lisp and Smalltalk failed because it was near impossible to share the code. Living images are really hard to merge. Smallltalk did eventually get a fantastic solution for code sharing between living images (Envy/Developer) but by that stage it was too late. All that philosophical guff about “worse is better” had nothing to do with the practical ease of sharing files rather than a tangled mess of code that Lisp and Smalltalk encouraged. Sharing files is definitely not “worse” by any definition.

igouy 3y ago
You say Smalltalk encouraged "a tangled mess of code" when we can all see that Smalltalk encouraged code sharing in external files: "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." 1984 Smalltalk-80 The Interactive Programming Environment page 46 https://rmod-files.lille.inria.fr/FreeBooks/TheInteractiveProgrammingEnv/TheInteractiveProgrammingEnv.pdf https://rmod-files.lille.inria.fr/FreeBooks/TheInteractivePr...
- smackeyacky 3y ago
  Sharing those changes was never that easy. Because it was encouraged to make additions and even changes to the base classes along with the project, we would inevitably end up with clashes. A typical scenario was filing in one programmers changes, then a second set of changes only to find they didn’t work together requiring a 3rd set of changes to be produced. Rinse and repeat in a big team and you’ve lost all the benefits of Smalltalk in hideous merges. The change sets did not have hash based versioning or anything like that, so we tried cramming entire classes into SCCS or PVCS which kinda worked but quickly got unmanageable as base class extensions grew. The Smalltalk change sets were fine for tracking one programmers work but quickly multiplied into a giant headache in any team.
  - igouy 3y ago
    > encouraged to make additions and even changes to the base classes By whom? "Guideline 120 Avoid modifying the existing behavior of base system classes." 1996 Smalltalk with Style page 95 https://rmod-files.lille.inria.fr/FreeBooks/WithStyle/SmalltalkWithStyle.pdf https://rmod-files.lille.inria.fr/FreeBooks/WithStyle/Smallt...
    - smackeyacky 3y ago
      You had to be there. Those books were not available when I was using Smalltalk and not all programmers really “got” the system or the implications of their changes on their team.
      - igouy 3y ago
        You must have been a very early user, this was published in 1984 — "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... Without a defined software development process, that everyone habitually uses, we can usually make "a tangled mess of code" with any programming language.
        smackeyacky 3y ago
        You do know the difference between citing a book and actually being there might be, right?
        3y ago

igouy 3y ago

You say Smalltalk encouraged "a tangled mess of code" when we can all see that Smalltalk encouraged code sharing in external files: "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." 1984 Smalltalk-80 The Interactive Programming Environment page 46 https://rmod-files.lille.inria.fr/FreeBooks/TheInteractiveProgrammingEnv/TheInteractiveProgrammingEnv.pdf https://rmod-files.lille.inria.fr/FreeBooks/TheInteractivePr...

smackeyacky 3y ago
Sharing those changes was never that easy. Because it was encouraged to make additions and even changes to the base classes along with the project, we would inevitably end up with clashes. A typical scenario was filing in one programmers changes, then a second set of changes only to find they didn’t work together requiring a 3rd set of changes to be produced. Rinse and repeat in a big team and you’ve lost all the benefits of Smalltalk in hideous merges. The change sets did not have hash based versioning or anything like that, so we tried cramming entire classes into SCCS or PVCS which kinda worked but quickly got unmanageable as base class extensions grew. The Smalltalk change sets were fine for tracking one programmers work but quickly multiplied into a giant headache in any team.
- igouy 3y ago
  > encouraged to make additions and even changes to the base classes By whom? "Guideline 120 Avoid modifying the existing behavior of base system classes." 1996 Smalltalk with Style page 95 https://rmod-files.lille.inria.fr/FreeBooks/WithStyle/SmalltalkWithStyle.pdf https://rmod-files.lille.inria.fr/FreeBooks/WithStyle/Smallt...
  - smackeyacky 3y ago
    You had to be there. Those books were not available when I was using Smalltalk and not all programmers really “got” the system or the implications of their changes on their team.
    - igouy 3y ago
      You must have been a very early user, this was published in 1984 — "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... Without a defined software development process, that everyone habitually uses, we can usually make "a tangled mess of code" with any programming language.
      - smackeyacky 3y ago
        You do know the difference between citing a book and actually being there might be, right?
        3y ago