lex wrote on Sun, 28 Nov 2004 12:32:30 -0400
It does not violate POLA in Squeak's case, because the LA is simply very large. Squeak is a late-bound computer authoring system,
Exactly: "system" and not language.
and it is a *feature* that you can type "Display" to access the low-level bitmap, "Sensor" to talk to the mouse, and "Smalltalk" to talk to the system itself.
True.
You are supposed to be able to read in audio and, in response, change the globals table and recompile classes. Yes it's weird, but that's the point. We don't know what future designers will want.
You lost me in the "read in audio" part. Do you mean a "voice fileIn" sort of thing in some future version?
Thus, if you were to implement Squeak in a language without global variables, what you'd do is create one scope that has all of Squeak's current globals, and then do everything inside that scope. All you'd do is replace global variables, with practically global variables.
Right, so let's think about the *system* thing again.
Imagine something very like Squeak but without any globals at all. But somehow I am able to create an instance of some class I have written and then invoke an inspector on it. On the other side of the screen I can see a window/icon/whatever that represents the mouse input (previously known as the global Sensor). What if I can drag-n-drop that into one of the instance variables in the open inspector? Now my object instance has access to the mouse, but not to the display - the least authority it needs to do its job.
I, as the all powerful programmer and the environment as my proxy do have lots and lots of authority. I don't see why I should have to give it all to every single object in the system.
But before people go crazy, yes I think it is possible to make an authoring system where the least authorities aren't so large. In fact, I agree that such an authoring system would be marevelous to have. It's just a completely different system than Squeak. Squeak is an environment for building its own successor! To achieve that goal, Squeak should allow fast iteration of design ideas. This fast iteration is incompatible with chopping authority into little bits.
That is not how it looks to me.
Let's plan that, if and when people do build secure authoring environments similar to Squeak of today, we still continue to have something highly maleable like the current Squeak. Speed of iteration matters, and is one of Squeak's biggest selling points. Squeak has lots of goodies, and it also has lots of flexibility for doing whatever crazy thing you can dream up. This is a rare and important combination, and we should be careful to hang on to it.
Good plan, but once again I see no relation between making things simpler and stricter at the language level and slowing things down or making them less flexible for the programmers.
Finally, if we had to choose just one system, for some reason, I would vote for the maleable one instead of the secure one. It is more important to build the next Great Thing, than to make a better Current Thing.
Think of SUnit tests and eXtreme Programming. In theory, the tests get in the way of changes but in practice they are a powerful help in doing radical refactoring since otherwise you are always too afraid stuff will break without you noticing it to ever do serious changes.
My opinion is that a proper factoring the system that would make it much more secure will have similar advantages in terms of maleability. Intentions will be clearer and you can be more confident that any problems with your changes will have instant consequences and will be easy to fix.
-- Jecel