3 ms·

That model stops working as soon as you try to distribute software at scale. You need some kind of standardisation and baseline. Otherwise your customisations c

That model stops working as soon as you try to distribute software at scale. You need some kind of standardisation and baseline. Otherwise your customisations conflict with someone else's customisations, with consequences that vary from mildly annoying to catastrophic. And the whole idea of shared software collapses. It would work if you had strict access control to each feature in a common code base. But Git hadn't been invented yet. The other issue is performance. Compiled ST isn't particularly slow, but you lose the modifiability. Interpreted ST has a mixed profile - some features are slow, some are fast - but generally it was slow compared to C. Today that doesn't matter so much, but it was a drawback at the time. It's a seductive model and I totally get the appeal. But it's not quite as straightforwardly superior as it might appear to be.

wonger_ 1y ago
Does Erlang have these same properties? From what I hear, it works great for distributed systems and modifying-while-running.
- toast0 1y ago
  Erlang systems don't do so well when multiple people are working on them with different understanding of what production is. (And especially if nobody actually knows). I don't know that you need 'strict access control' as proposed, but you do need coordination, and a source code repository is a way to manage coordination. Erlang doesn't have a different mode for fixed vs loadable code, although you may need to write code differently in order to be able to hotload changes, and that could affect performance; some code naturally fits the idioms needed though. I find it amazingly valuable to be able to change the program without having to lose the program state; but it requires different thinking, and it is easy to mess things up in exciting ways that are different than many other systems. It's amazing to fix a bug and deploy it in seconds into a live system with millions of active connections; it's also amazing when you try to fix a bug and break millions of active connections in seconds, but in a negative way, because now you and your users have to pay the costs of reestablishing all of those connections. OTOH, the key issue is interchange of state and messages between versions, and that's an issue that comes up in almost all distributed systems that update without downtime, so most people have to deal with that issue anyway, just usually not within the much smaller scope of a single task.
kens 1y ago
As far as performance, the Alto team described the performance of Smalltalk as between "majestic" and "glacial". From my experience with the Alto, Smalltalk seemed unusably slow, and I'm amazed that they could actually accomplish anything with it.
- speedbird 1y ago
  With the ParcPlace flavour teamwork with Envy version control was pretty slick. And in performance it was mostly compiled to bytecode with some cunning tricks in place to make interactive debugging appear to work at the source level. Truly great environment for exploratory development: concrete example, while building a comms server I could inspect why message handling failed, patch code, rerun from failure, much faster cycle time than most other langs/envs.
- jecel 1y ago
  The Xerox Dorado, an ECL beast evolved from the Alto, was considered the only machine to offer a good Smalltalk experience when Smalltalk-80 was initially released. The Xerox Dolphin, for example, was only about "0.1 Dorados" despite being a serious improvement on the Alto. The Apple Lisa was only about 0.05 Dorados. That level of performance was only achieved by PCs when we got 50MHz 486 (for purely interpreted Smalltalk-80 virtual machines, with JITs much slower computers could match the Dorado).
- uticus 1y ago
  not sure about context or timing, but there was work put towards improving performance around the same time: https://archive.org/details/ungar-smalltalk https://archive.org/details/ungar-smalltalk (pub Feb 1986)
- datavirtue 1y ago
  For a similar experience, boot up Windows 3.1 on a machine with 1MB RAM.
mkfs 1y ago
> But Git hadn't been invented yet. Git isn't the first or oldest DVCS. Smalltalk actually had multiple DVCSs, including ENVY (VA/Cincom), which dates back to the mid 90s, and Monticello (Squeak/Pharo), which dates to the early 2000s--both of which predating git.
graemep 1y ago
> That model stops working as soon as you try to distribute software at scale. True, but lots of people do not need to distribute software at scale. IIRC Pharo has a way of exporting the current image to files for version control. That should solve the problem of multiple developers working on the code. You can modify while running to try things, and then commit the final result to version control.
johnlorentzson 1y ago
With regards to performance, Craig Chambers's thesis on the Just-In-Time compiler for Self proves pretty definitively that a language as (or more) flexible as Smalltalk can be very performant without losing any dynamic properties. It certainly isn't an easy compiler/runtime to recreate for any given language, but it does exist. It didn't exist at the time you're referring to however, so in that context the point does stand, mostly. I believe there was some form of flexible compiled optimization for Smalltalk (since Chambers's thesis references it as prior work) but I forget when that was and how commonly used it was.
- rjsw 1y ago
  The first JIT was for Smalltalk, running on a 68020 system.
  - johnlorentzson 1y ago
    That sounds about right. (Just to clarify, what I was referring to with "did not exist at the time" was specifically Self's JIT and its new techniques.)
- uticus 1y ago
  Chamber's thesis was '92 if i'm looking correctly (https://www.cs.tufts.edu/~nr/cs257/archive/craig-chambers/thesis.pdf https://www.cs.tufts.edu/~nr/cs257/archive/craig-chambers/th...), Ungar's thesis from '86 greatly predates it: https://archive.org/details/ungar-smalltalk https://archive.org/details/ungar-smalltalk
lproven 1y ago
> stops working as soon as you try to distribute software at scale. I disagree – just make it read-only – but to illustrate my point, let me try to invert your point. You're saying that the Lisp/Smalltalk software creation model doesn't scale and only mass-produced software can. Instead of the traditional car analogy, let me use clothing instead. Even more people use clothes than cars. "The idea of hand-making bespoke clothing stops working as soon as you try to distribute clothes at scale. There are billions of people and they're all slightly different sizes and shapes. You can't customise clothes for them all! "The only way we can clothe billions of people is if they all wear the same thing. One-offs worked when we only had a small population and only the rich got a choice. There was no other way. But since then, we invented elastic and zips and belts. This way we can give everyone a simple all-in-one coverall, a sort of jumpsuit, and using a few zips and elasticated bands and some straps to shorten or lengthen the arms and legs, it will fit everyone. At the worst we can make a few sizes and they will scale. It's all about scale, and we have to make sacrifices if we want something that scales efficiently."
- lproven 1y ago
  [flagged]
igouy 1y ago
> standardisation and baseline 1984 "Smalltalk-80 The Interactive Programming Environment" page 500 "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." https://rmod-files.lille.inria.fr/FreeBooks/TheInteractiveProgrammingEnv/TheInteractiveProgrammingEnv.pdf https://rmod-files.lille.inria.fr/FreeBooks/TheInteractivePr... ~ Later "ENVY/Developer" https://www.google.com/books/edition/Mastering_ENVY_Developer/ld6E19QIMo4C?hl=en&gbpv=1&dq=envy+developer https://www.google.com/books/edition/Mastering_ENVY_Develope... https://archive.esug.org/HistoricalDocuments/TheSmalltalkReport/91_95/SMAL0202.PDF https://archive.esug.org/HistoricalDocuments/TheSmalltalkRep...

wonger_ 1y ago

Does Erlang have these same properties? From what I hear, it works great for distributed systems and modifying-while-running.

toast0 1y ago
Erlang systems don't do so well when multiple people are working on them with different understanding of what production is. (And especially if nobody actually knows). I don't know that you need 'strict access control' as proposed, but you do need coordination, and a source code repository is a way to manage coordination. Erlang doesn't have a different mode for fixed vs loadable code, although you may need to write code differently in order to be able to hotload changes, and that could affect performance; some code naturally fits the idioms needed though. I find it amazingly valuable to be able to change the program without having to lose the program state; but it requires different thinking, and it is easy to mess things up in exciting ways that are different than many other systems. It's amazing to fix a bug and deploy it in seconds into a live system with millions of active connections; it's also amazing when you try to fix a bug and break millions of active connections in seconds, but in a negative way, because now you and your users have to pay the costs of reestablishing all of those connections. OTOH, the key issue is interchange of state and messages between versions, and that's an issue that comes up in almost all distributed systems that update without downtime, so most people have to deal with that issue anyway, just usually not within the much smaller scope of a single task.

kens 1y ago

As far as performance, the Alto team described the performance of Smalltalk as between "majestic" and "glacial". From my experience with the Alto, Smalltalk seemed unusably slow, and I'm amazed that they could actually accomplish anything with it.

speedbird 1y ago
With the ParcPlace flavour teamwork with Envy version control was pretty slick. And in performance it was mostly compiled to bytecode with some cunning tricks in place to make interactive debugging appear to work at the source level. Truly great environment for exploratory development: concrete example, while building a comms server I could inspect why message handling failed, patch code, rerun from failure, much faster cycle time than most other langs/envs.
jecel 1y ago
The Xerox Dorado, an ECL beast evolved from the Alto, was considered the only machine to offer a good Smalltalk experience when Smalltalk-80 was initially released. The Xerox Dolphin, for example, was only about "0.1 Dorados" despite being a serious improvement on the Alto. The Apple Lisa was only about 0.05 Dorados. That level of performance was only achieved by PCs when we got 50MHz 486 (for purely interpreted Smalltalk-80 virtual machines, with JITs much slower computers could match the Dorado).
uticus 1y ago
not sure about context or timing, but there was work put towards improving performance around the same time: https://archive.org/details/ungar-smalltalk https://archive.org/details/ungar-smalltalk (pub Feb 1986)
datavirtue 1y ago
For a similar experience, boot up Windows 3.1 on a machine with 1MB RAM.

mkfs 1y ago

> But Git hadn't been invented yet. Git isn't the first or oldest DVCS. Smalltalk actually had multiple DVCSs, including ENVY (VA/Cincom), which dates back to the mid 90s, and Monticello (Squeak/Pharo), which dates to the early 2000s--both of which predating git.

graemep 1y ago

> That model stops working as soon as you try to distribute software at scale. True, but lots of people do not need to distribute software at scale. IIRC Pharo has a way of exporting the current image to files for version control. That should solve the problem of multiple developers working on the code. You can modify while running to try things, and then commit the final result to version control.

johnlorentzson 1y ago

With regards to performance, Craig Chambers's thesis on the Just-In-Time compiler for Self proves pretty definitively that a language as (or more) flexible as Smalltalk can be very performant without losing any dynamic properties. It certainly isn't an easy compiler/runtime to recreate for any given language, but it does exist. It didn't exist at the time you're referring to however, so in that context the point does stand, mostly. I believe there was some form of flexible compiled optimization for Smalltalk (since Chambers's thesis references it as prior work) but I forget when that was and how commonly used it was.

rjsw 1y ago
The first JIT was for Smalltalk, running on a 68020 system.
- johnlorentzson 1y ago
  That sounds about right. (Just to clarify, what I was referring to with "did not exist at the time" was specifically Self's JIT and its new techniques.)
uticus 1y ago
Chamber's thesis was '92 if i'm looking correctly (https://www.cs.tufts.edu/~nr/cs257/archive/craig-chambers/thesis.pdf https://www.cs.tufts.edu/~nr/cs257/archive/craig-chambers/th...), Ungar's thesis from '86 greatly predates it: https://archive.org/details/ungar-smalltalk https://archive.org/details/ungar-smalltalk

lproven 1y ago

> stops working as soon as you try to distribute software at scale. I disagree – just make it read-only – but to illustrate my point, let me try to invert your point. You're saying that the Lisp/Smalltalk software creation model doesn't scale and only mass-produced software can. Instead of the traditional car analogy, let me use clothing instead. Even more people use clothes than cars. "The idea of hand-making bespoke clothing stops working as soon as you try to distribute clothes at scale. There are billions of people and they're all slightly different sizes and shapes. You can't customise clothes for them all! "The only way we can clothe billions of people is if they all wear the same thing. One-offs worked when we only had a small population and only the rich got a choice. There was no other way. But since then, we invented elastic and zips and belts. This way we can give everyone a simple all-in-one coverall, a sort of jumpsuit, and using a few zips and elasticated bands and some straps to shorten or lengthen the arms and legs, it will fit everyone. At the worst we can make a few sizes and they will scale. It's all about scale, and we have to make sacrifices if we want something that scales efficiently."

lproven 1y ago
[flagged]

igouy 1y ago

> standardisation and baseline 1984 "Smalltalk-80 The Interactive Programming Environment" page 500 "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." https://rmod-files.lille.inria.fr/FreeBooks/TheInteractiveProgrammingEnv/TheInteractiveProgrammingEnv.pdf https://rmod-files.lille.inria.fr/FreeBooks/TheInteractivePr... ~ Later "ENVY/Developer" https://www.google.com/books/edition/Mastering_ENVY_Developer/ld6E19QIMo4C?hl=en&gbpv=1&dq=envy+developer https://www.google.com/books/edition/Mastering_ENVY_Develope... https://archive.esug.org/HistoricalDocuments/TheSmalltalkReport/91_95/SMAL0202.PDF https://archive.esug.org/HistoricalDocuments/TheSmalltalkRep...