5 ms·

I love the idea of prototypes, and self, but I always use classes. There's this idea of the self prototyping environment you can extend, which is great for prot

I love the idea of prototypes, and self, but I always use classes. There's this idea of the self prototyping environment you can extend, which is great for prototyping (perhaps), but when it comes to professional programming we want a program to deploy and no one really touches the internal structure, so classes and deployment win out. The same for smalltalk, you don't want to deploy an environment that your users can extend - except perhaps in research environments. The other thing I suppose is multi developer environments - classes and compilation win out over prototyping because they're easier to split up. There might be other reasons, but that's why I always come back to class based programming, the idea of prototypes is very enticing though. Edit: though I have started to use a pseudo prototyping environment - breakpoints and evaluate when things get complex, though its not the same.

Lichtso 7y ago
> you don't want to deploy an environment that your users can extend What is so bad about that? And isn't it common practice around computer games for example, which can be modded and extended by custom user content?
- chadcmulligan 7y ago
  yes probably - but I suppose the limit there is controlling what they can extend? The other thing with games is performance - prototype languages are slower in general. I'm not against them - these are reasons I can see for not using prototype languages. Edit: I suppose to the environment a developer wants isn't the environment that a game user wants, like a game user wants to just extend a few things - but having the whole self environment for arguments sake would be fairly intimidating I'd imagine.
  - kazagistar 7y ago
    The nicest games to mod are the ones with languages that allow reflection to replace anything and everything.
- scroot 7y ago
  This was the view of "what personal computing would be like" held by the original LRG team at PARC. There would be no distinction between "user" and "programmer," since using the system would at some level involve some type of programming. All of today's computing culture and the systems we use heavily reflect the opposite view. It's hard for us to imagine, since programming is a kind of scribal trade.
  - ken 7y ago
    I disagree that all of our computing systems keep them apart. We’ve got systems like Bash, and Excel. Even when I’m not doing “programming”, I’m doing programming. I wish more systems had that flexibility. Even when the average user isn’t writing programs in it (like the web), all of the long-lived platforms today are programmable.
    - scroot 7y ago
      > all of the long-lived platforms today are programmable Sure, programmable by what today we'd call "programmers" but certainly not by "users." This is because programming has become a niche trade (as I said before, like a scribal culture). I'll give an example. Most users' experience with their host Operating System involves prodigious use of buttons. They know how buttons work and they know how to interact with them. But in all these OSes it is extremely difficult for a user to make a button that does something they want, then, say, place it on their desktop for future use. In the past there were really good attempts at authorship in computing media (which is more like what the LRG was going for with Smalltalk etc), including Hypercard. In the latter system, you could pop open a button and see how it worked in a comprehensible scripting language. You could copy the button and paste it somewhere else. You cannot do any of this with buttons in the major OSes. The capability is not there.* The only option available to "users" is to learn a full fledged, general purpose programming language with all the pitfalls that entails, which means learning build systems and all the rest. At that point they have to become what today we call a "programmer," ie a scribal-programmer. Our dominant systems have been explicitly designed for a strict delineation between scribal-programmers and consumer-users. That's the rub. * - AppleScript is a so-so attempt at this, but even that has been allowed to die on the vine.
- e12e 7y ago
  I always used to be a bit lackluster about the idea of deploying smalltalk applications for a similar reason - too powerful introspection and debug tools that are too easy for an end user to open accidentally, and be confused by. But now, switching between a terminal that uses shift-ctrl-c for copy, and outlook/o365 in chrome, I often accidentally open developer tools in my email "application"... And wonder how much better we might be off with a solid smalltalk (or strongtalk, self) system -- than the current mix of crappy web apps and crappy electron behemoths... I should note that it's generally possible to strip out/hide and disable most of the introspection stuff from smalltalk applications and ship more end-user style applications.
  - deleted 7y ago
    [deleted]
xkriva11 7y ago
A good trade-off is to have a prototype-based object system but use it as a class-based system. You can benefit from a rigid system structure, and organization like Smalltalk has (it is easier to make good tools for it) but use prototype-based features during debugging and where it really makes sense.
eru 7y ago
It might be interesting for you to look at this issue from an functional programming point of view. With FP you can simulate both class based approaches and prototype based approaches. The slightly 'warped' perspective of the FP lens might give you more insights into your question. (I can expand, if you are interested.)

Lichtso 7y ago

> you don't want to deploy an environment that your users can extend What is so bad about that? And isn't it common practice around computer games for example, which can be modded and extended by custom user content?

chadcmulligan 7y ago
yes probably - but I suppose the limit there is controlling what they can extend? The other thing with games is performance - prototype languages are slower in general. I'm not against them - these are reasons I can see for not using prototype languages. Edit: I suppose to the environment a developer wants isn't the environment that a game user wants, like a game user wants to just extend a few things - but having the whole self environment for arguments sake would be fairly intimidating I'd imagine.
- kazagistar 7y ago
  The nicest games to mod are the ones with languages that allow reflection to replace anything and everything.
scroot 7y ago
This was the view of "what personal computing would be like" held by the original LRG team at PARC. There would be no distinction between "user" and "programmer," since using the system would at some level involve some type of programming. All of today's computing culture and the systems we use heavily reflect the opposite view. It's hard for us to imagine, since programming is a kind of scribal trade.
- ken 7y ago
  I disagree that all of our computing systems keep them apart. We’ve got systems like Bash, and Excel. Even when I’m not doing “programming”, I’m doing programming. I wish more systems had that flexibility. Even when the average user isn’t writing programs in it (like the web), all of the long-lived platforms today are programmable.
  - scroot 7y ago
    > all of the long-lived platforms today are programmable Sure, programmable by what today we'd call "programmers" but certainly not by "users." This is because programming has become a niche trade (as I said before, like a scribal culture). I'll give an example. Most users' experience with their host Operating System involves prodigious use of buttons. They know how buttons work and they know how to interact with them. But in all these OSes it is extremely difficult for a user to make a button that does something they want, then, say, place it on their desktop for future use. In the past there were really good attempts at authorship in computing media (which is more like what the LRG was going for with Smalltalk etc), including Hypercard. In the latter system, you could pop open a button and see how it worked in a comprehensible scripting language. You could copy the button and paste it somewhere else. You cannot do any of this with buttons in the major OSes. The capability is not there.* The only option available to "users" is to learn a full fledged, general purpose programming language with all the pitfalls that entails, which means learning build systems and all the rest. At that point they have to become what today we call a "programmer," ie a scribal-programmer. Our dominant systems have been explicitly designed for a strict delineation between scribal-programmers and consumer-users. That's the rub. * - AppleScript is a so-so attempt at this, but even that has been allowed to die on the vine.
e12e 7y ago
I always used to be a bit lackluster about the idea of deploying smalltalk applications for a similar reason - too powerful introspection and debug tools that are too easy for an end user to open accidentally, and be confused by. But now, switching between a terminal that uses shift-ctrl-c for copy, and outlook/o365 in chrome, I often accidentally open developer tools in my email "application"... And wonder how much better we might be off with a solid smalltalk (or strongtalk, self) system -- than the current mix of crappy web apps and crappy electron behemoths... I should note that it's generally possible to strip out/hide and disable most of the introspection stuff from smalltalk applications and ship more end-user style applications.
- deleted 7y ago
  [deleted]

xkriva11 7y ago

A good trade-off is to have a prototype-based object system but use it as a class-based system. You can benefit from a rigid system structure, and organization like Smalltalk has (it is easier to make good tools for it) but use prototype-based features during debugging and where it really makes sense.

eru 7y ago

It might be interesting for you to look at this issue from an functional programming point of view. With FP you can simulate both class based approaches and prototype based approaches. The slightly 'warped' perspective of the FP lens might give you more insights into your question. (I can expand, if you are interested.)