29 ms·

I used to program in Smalltalk and as it faded from popularity I wondered why. It seemed so much better in many ways. Now I think the problem with the image-ba

I used to program in Smalltalk and as it faded from popularity I wondered why. It seemed so much better in many ways. Now I think the problem with the image-based programming is that while it is easy for a single programmer it makes collaboration more difficult. Why? Because it is very difficult or impossible to "merge" two or more images. My changes might work when added to a default virgin image, but there is no such thing as virgin default image when every Smalltalk provider has their own and multiple versions of them. Any image is as good as any other. The ability to change anything in the image really means the ability to depend on any fact about the current image. If you apply your changes in an environment/image where any one of those facts no longer holds you will get unpredictable results.

karmakaze 5y ago
That's really well said. I've read this before but the way you've described it makes more sense to me. I can see that a similar problem made lisp difficult to catch on, as each application or company was its own ecosystem creating its own dialect with so many bits and pieces that the core language is such a small part as to not really be considered transferable knowledge between shops. I thought making it all cloud-based with realtime collaboration would help, but it wouldn't be nearly enough. At scale there needs to be ensurances of stability--something like realtime tests. I have no idea how something like that could be made to work efficiently enough to be effective.
- galaxyLogic 5y ago
  It is also interesting to think from the viewpoint of Curry-Howard Isomorphism. Programs are proofs. Progress in mathematics relies on the ability of mathematicians to use other mathematicians proofs as their lemmas. That is possible because all mathematicians speak the same language. But if every programmer has their own version of the base-library that hinders collaboration. And still the base-library must also somehow evolve all the time. Like you say, not an easy problem, but as in mathematics the ability to use other people's software as "lemmas" I think is (or should be) the key problem of Software Engineering research.
  - karmakaze 5y ago
    I can relate this to what does happen between ecosystems. We 'black-box' subsets of the problem by splitting up into front-end, back-end, microservices, datastores, etc. This does give some interoperability between languages/ecosystems. Within each language/ecosystem there are library/packages that can serve as a shared/reusable base but still have many challenges in that there typically is no agreed-upon contract. We're even drifting from stability that we had before in that languages themselves evolve more rapidly now often having version/point-version numbers or add-in extensions. Another thing that keeps happening is that languages become popular because of the platform it's tied to gets popular with little correlation to how good the language is in any sense, other than it being adequate to produce a working program. There's at least some possibility of convergence with LLVM backends, wasm or jvm and .NET. I think there will still be more (low-code, online collaborative) before there's any culling and less.
    - galaxyLogic 5y ago
      > there typically is no agreed-upon contract. True. It's the Wild West, at this point

karmakaze 5y ago

That's really well said. I've read this before but the way you've described it makes more sense to me. I can see that a similar problem made lisp difficult to catch on, as each application or company was its own ecosystem creating its own dialect with so many bits and pieces that the core language is such a small part as to not really be considered transferable knowledge between shops. I thought making it all cloud-based with realtime collaboration would help, but it wouldn't be nearly enough. At scale there needs to be ensurances of stability--something like realtime tests. I have no idea how something like that could be made to work efficiently enough to be effective.

galaxyLogic 5y ago
It is also interesting to think from the viewpoint of Curry-Howard Isomorphism. Programs are proofs. Progress in mathematics relies on the ability of mathematicians to use other mathematicians proofs as their lemmas. That is possible because all mathematicians speak the same language. But if every programmer has their own version of the base-library that hinders collaboration. And still the base-library must also somehow evolve all the time. Like you say, not an easy problem, but as in mathematics the ability to use other people's software as "lemmas" I think is (or should be) the key problem of Software Engineering research.
- karmakaze 5y ago
  I can relate this to what does happen between ecosystems. We 'black-box' subsets of the problem by splitting up into front-end, back-end, microservices, datastores, etc. This does give some interoperability between languages/ecosystems. Within each language/ecosystem there are library/packages that can serve as a shared/reusable base but still have many challenges in that there typically is no agreed-upon contract. We're even drifting from stability that we had before in that languages themselves evolve more rapidly now often having version/point-version numbers or add-in extensions. Another thing that keeps happening is that languages become popular because of the platform it's tied to gets popular with little correlation to how good the language is in any sense, other than it being adequate to produce a working program. There's at least some possibility of convergence with LLVM backends, wasm or jvm and .NET. I think there will still be more (low-code, online collaborative) before there's any culling and less.
  - galaxyLogic 5y ago
    > there typically is no agreed-upon contract. True. It's the Wild West, at this point