4 ms·

Discussions about Smalltalk almost always remind me of Self[0] from Sun. It is an extremely simple prototype-based programming language. An object can have many

Discussions about Smalltalk almost always remind me of Self[0] from Sun. It is an extremely simple prototype-based programming language. An object can have many "parents", and defines properties on itself to expose an interface. It's really fun to mess around with. The Morphic UI is kind of archaic though. [0]: https://selflanguage.org/ https://selflanguage.org/

discreteevent 6y ago
Do you mean that the morphic ui is archaic looking? Because my impression of it is that it is still ahead of its time technically.
- Rochus 6y ago
  What you can download from https://selflanguage.org/ https://selflanguage.org/ looks rather archaic, not the improved version implemented on top of Squeak which looks and feals really fancy.
  - russellallen 6y ago
    Unfortunately the version in Squeak is, in my opinion, fancy looking but a backwards step from the Self version in terms of the underlying system. Morphic doesn't seem to really fit all that well with class based systems.
    - jecel 6y ago
      While being class based does make Squeak's Morphic a bit more awkward than Self's, the big difference is that it is a hybrid system that can run older MVC (Model View Controller) applications with little or no modification. That means that there are two different ways of doing most things and someone looking for examples to copy might run across the MVC version instead of the "proper" Morphic version.
      - russellallen 6y ago
        My experience of doing morphic stuff in both Squeak and Self, is that in Squeak there was a bit of a disconnect between the instance side and the class side - you could click together morphs, but in the end you had to write code in morphic classes to reconstruct those morphs. There wasn't any automatic way to go from the morph instances to equivalent morph constructors, or any way to save the morph instances to copy and use later. So I ended up ignoring the instance manipulation and just coded morph creation methods. In this way, the morph class hierarchy became much like a hierarchy of factories. This mattered when I was doing a GUI to run on my Compaq iPaq because a lot of morphs (such as menus) were being created afresh each time they were needed. This was really slow and I only made it usable by caching the created menus and only displaying them when needed. On Self I would have just copied the previously constructed menuMorph prototype and displayed it (if of course I had been able to port the huge pile of C++ that is the Self VM to the iPaq :) This was ages ago though and I haven't played properly with modern Squeak or Cuis.
commandlinefan 6y ago
I've never used Self personally, but I remember reading that JavaScript's OO provisions are modeled after it rather than, say, C++ or Java. Does that sound right to you? I always thought Javascript's class provisions were a bit counterintuitive myself.

discreteevent 6y ago

Do you mean that the morphic ui is archaic looking? Because my impression of it is that it is still ahead of its time technically.

Rochus 6y ago
What you can download from https://selflanguage.org/ https://selflanguage.org/ looks rather archaic, not the improved version implemented on top of Squeak which looks and feals really fancy.
- russellallen 6y ago
  Unfortunately the version in Squeak is, in my opinion, fancy looking but a backwards step from the Self version in terms of the underlying system. Morphic doesn't seem to really fit all that well with class based systems.
  - jecel 6y ago
    While being class based does make Squeak's Morphic a bit more awkward than Self's, the big difference is that it is a hybrid system that can run older MVC (Model View Controller) applications with little or no modification. That means that there are two different ways of doing most things and someone looking for examples to copy might run across the MVC version instead of the "proper" Morphic version.
    - russellallen 6y ago
      My experience of doing morphic stuff in both Squeak and Self, is that in Squeak there was a bit of a disconnect between the instance side and the class side - you could click together morphs, but in the end you had to write code in morphic classes to reconstruct those morphs. There wasn't any automatic way to go from the morph instances to equivalent morph constructors, or any way to save the morph instances to copy and use later. So I ended up ignoring the instance manipulation and just coded morph creation methods. In this way, the morph class hierarchy became much like a hierarchy of factories. This mattered when I was doing a GUI to run on my Compaq iPaq because a lot of morphs (such as menus) were being created afresh each time they were needed. This was really slow and I only made it usable by caching the created menus and only displaying them when needed. On Self I would have just copied the previously constructed menuMorph prototype and displayed it (if of course I had been able to port the huge pile of C++ that is the Self VM to the iPaq :) This was ages ago though and I haven't played properly with modern Squeak or Cuis.

commandlinefan 6y ago

I've never used Self personally, but I remember reading that JavaScript's OO provisions are modeled after it rather than, say, C++ or Java. Does that sound right to you? I always thought Javascript's class provisions were a bit counterintuitive myself.