goran.hultgren@bluefish.se wrote:
Projects vs Modules
I have read the stuff on the Swiki and my naive view is this:
A Module is a published piece of code.
Right, an abstract (piece of a) program with no reference whatsoever to how it is represented, run, or anything. Effectively a sort-of-mathematical abstraction.
It is not a "binary deliverable". But you can download/load/activate them in your environment. I think it is good that they are not binary and I think it would be much harder to build such a system with the functionality that Henrik have put in there if they were binary. Being non binary also makes it possible to manipulate these things more easily. On the other hand the repository is a pluggable component so that we can have different kinds of repositorys. For example, we could have a repository implementation that uses ImageSegments or something to increase loading speed.
A Project is more of a published binary deliverable. It surely can/could contain one or more modules but it also contains live instances etc. It is in my eyes analogous to the "binary download" you see everywhere on the Internet - just click and go. Typically not used by developers when they need a module to use in their own project but more for Squeak endusers "surfing for content".
I would like to distinguish Projects from Components--a Component is a concrete representation of the code in a Module, that can be dynamically loaded and unloaded. (Components also imply dynamic hook-up and such, which is a much smaller problem in Smalltalk than in e.g. C++, which has no standard representation for program meta-objects. Smalltalk already has all/most of that.) So a Component = a Module or Modules as concretely represented in Squeak (class and compiledmethod objects, etc.).
A Project is more than just this.
A Project is more of a published binary deliverable. It surely can/could contain one or more modules but it also contains live instances etc.
I assume what you read was http://minnow.cc.gatech.edu/squeak/2058.
Importantly, Projects have contents, as in "content provider", not just code (but it may contain code). This is what you call live instances, and I think this is the essential difference between Projects and Components.
What projects really are today is kind of vague, but the best notion I've been able to come up with is "the kind of thing Alan wants kids to create with their DynaBooks". But Alan/SqC also seems to have frequently changed their mind about^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H refined the notion of what Projects are.
I proposed Creation as the best name I could come up with instead of Project, which is extraordinarily vague and generic for such a specific use, and gives poor hints to what this "thing" is and does. A Creation is a collection of "hand-made" objects that someone has created (with a nod to Koestler with the colored planes). See the above page for a discussion of this.
As I see it, as concepts, Components are layered on top of/incorporate Modules, and Creations extend Components to include hand-made objects. Eventually.
_____ a Creation ( ) ¨¨|¨¨ _____ Components ( ) * (0 or more) ¨¨|¨¨ _____ Module(s) ( ) + (1 or more) ¨¨¨¨¨
Example:
I write a cool Morphic game including classes for general animation. The code is composed of a Module representing the Game itself with 2 more general submodules for Animation and Sound. They are not really blessed to go into the "base image" so I put everything in "People/gh/CoolGame". Ok, I upload it all onto the virtual module server (more on that later) so that people easily can load this module.
Yes, this is enough if all your objects can be programmatically generated by your code.
But I also set up a Project where I start the Game up with a centered window and I also type in a todo-list in an open Workspace. Finally I smack in a nice looking background image and then publish the Project onto Bobs superswiki AND also to another superswiki in Sweden containing only Morphic games (just fantasy).
These are "hand-made" (ie. non-programmatically generated) objects, which code isn't sufficient for creating (without taking extreme measures). At least code isn't convenient for creating them. You need the ability to conveniently (distribute and) load _objects_. This is the added role I assign to Creations. I think Creation also implies this having to do with "hand-made" objects (vs. code-generated).
So, developers typically load the module to get to the code and perhaps reuse my Animation module or just check out how the game was done.
Right, just to get the code, Modules are enough. Components/image segments may be convenient (think the 1MB refactoring browser).
End users typically find the project and loads that - it probably is faster and they get a "just point and click" experience. They get the modules with the project, but that is just a bonus.
Right, this to get the non-code objects too.
In general, I think Repositories should be a general facility for conveniently storing and accessing anything Squeak-related, including e.g. Projects/Creations, so that you can just give a path to a Project, or help pages, or you personal preferences file, or whatever, and Squeak will be able to locate the files for you.
regards, Göran
So what we really need is for SqC to agree with this ;-)
Henrik
Henrik wrote:
But Alan/SqC also seems to have frequently changed their mind about^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H refined the notion of what Projects are.
Be careful! Those key bindings might get you into trouble one day. ;) ;) ;)
I proposed Creation as the best name I could come up with instead of Project, which is extraordinarily vague and generic for such a specific use, and gives poor hints to what this "thing" is and does. A Creation is a collection of "hand-made" objects that someone has created (with a nod to Koestler with the colored planes). See the above page for a discussion of this.
I think at this point, it's really difficult to tell what's going to work well, and what won't work at all. So far, we've attempted to define:
Project Package Module Creation Component
and I'm sure I left out a few...is anyone ever going to be able to keep these things straight? Certainly not without some hands on use. Once something is finally released, we'll start solving the problems out of necessity. When we start playing with the code and seeing what works, and what doesn't, we'll all have a much better understanding of the issues.
- Stephen
Folks:
I don't want to enter into this discussion in a major way, but I also don't want to be silent lest it appear that I am ignoring you.
I have spent significant time reading the postings in this thread this week. And some things do seem to require a few comments from me.
First, I really must apologize if I have upset anyone by my mail here. I think that at least Andreas was a bit impatient with me. I didn't mean to annoy anyone; please accept my apologies if I did.
I care about Squeak modules because I believe that Squeak is the best tool that I have right now. The reason that it is the best is that Andreas and many others have worked very hard on it. My contributions are tiny. I appreciate what you are doing. And I accept that you probably know a lot more about the domain than I do. Andreas' question about the filled polygons and the delauney triangulations made this point: no, I would not come up with that solution, because I haven't a clue what a delauney triangulation is.
The place that I was starting from is that not only should there be a user story -- and I liked the story that Andreas took the time to write -- but that should be consistent and complete. So when I see something from Henrik and something from Andreas that appear to conflict, it means either that the story need to be refined, or that I have not yet understood.
Of course, I accept the position that it would be a mistake to spend a lot of time writing documentation before implementation starts, knowing that some of the concepts would change. That was why I made the XP analogy -- not because I belive that XP is the only good way to do development, but because it is the way of developing without up-front design with which I was most comfortable.
One place in the discussion where "the other shoe dropped" for me was when someone said that as I write code in my Squeak environment, the _system_ notices that I'm adding a method to a class that is not in my module, and therefore creates a DeltaModule to hold it. This makes sense to me; this is why DeltaModules are more than a convention: they are enforced by the tools! I hadn't realized before that this was how it worked; I had assumed that the programmer has to do the right thing "by hand". This was a big "aha" for me.
Part of me can't wait to get the release so that I can try this all out, but I also really appreciate Alan's comments on wanting to avoid prematurely making assumptions based on early code. Alan also made the really important point that the in-memory representation of a loaded module is not what matters: it is the "abstract syntax" of the external representation. So, for example, on the issue of whether a submodule "knows" about its super module: this question needs to be answered with respect to the abstraction of module, not the in-memory representation. The representation might build a (collection of) references to supermodules as an optimization, without compromising reuse, but the abstraction should surely not have any such reference.
The one inconsistency that still troubles me, however, is the one that started this thread. Henrik insists that a module must be "independent of all others". This seems to be a cornerstone for him:
At 14:55 +0200 2001.10.25, Henrik Gedenryd wrote:
There has been a lot of discussion (and little agreement??) on this list about what we mean by a "module". Cutting through the nuisances I suspect that most people could accept the following: A module is an *atomic* unit of functionality (code, objects, whatever) with an independent existence that can be incorporated into a program (image, whatever). The atomisity aspect is very important. If loading a module, the normal expectation is that you get the whole thing.
I would agree, if by "independent existence" or otherwise you mean that each module should be independent of all others. This is why I've been surprised and bewildered when people have suggested that modules don't always have their own namespaces, or even that modules and namespaces are orthogonal.
I can reconcile this with the need to use code from other modules, buy saying that that those other modules must either be parameters, or must be "imported". That is, an explicit dependency is set up saying that WebBrowser module uses HTML module, or whatever.
For this reason, Henrick says that
module "FooImplementation" extends class Object with method isFoo
is not a self-contained unit at all, since it modifies the contents of another module, the--the one holding the class Object.
Hence the extensions to Object cannot be a module, right?
Hence, they have to be something else, because we all know that we need to do this kind of thing sometimes.
That something else is a DeltaModule!
And here is the part where I'm still confused: this seems to imply that DelatModules _are not modules_. Because they do what Modules cannot and must not be allowed to do, that is, to modify some other module.
So, DeltaModule is a bad name. But, most importantly, DeltaModules must not be allowed inside modules, because then the Module does what it is not permitted to do.
But we _do_ have to create some kind of packaging mechanism for whole applications, which typically require BOTH new modules and changes to existing modules. Which was why I suggested PackageModule.
I think that the current situation is that
(1) Modules that contain DelatModules can change other modules, but that (2) Modules that do not contain DeltaModules must be independent entities that depend only on their parameters and imports.
I can live with that, but it does not seem to be a very clean foundation on which to rest such an important cornerstone.
I'm sorry to belabour this, but I make my living from explaining ideas to others, and I know for experience that names that don't mean what they appear to mean are a big inhibitor to understanding. And exceptions to rules are another. I've been struggling to learn about Envy this week, and the naming that they adopt certainly doesn't help either.
Well, that's far more than I intended to write -- time to quit for this evening. Thanks again for paying so much attention.
And finally -- there is no need to CC me on this thread; I get the whole Squeak list, and the original and the cc both get filtered into the same "Modular Squeak" folder. So I just see it all twice.
Andrew
Here's an idea: I think the idea of being able to manipulate and analyze modules *without* loading them is sufficiently important that the initial release of the module system should *not* actual support module loading. Such a system will still be useful for *describing*, say, how to partition an image. Come to think of it, the actual loading should be a completely separate, er, module. That way you can use it for directly assembling production images from makefiles (without ever running a single bytecode of that image). You'll also have a nice *clean* structure (unfettered by the implementations of method dictionaries and symbols etc) with which to perform analysis. Actual loading of modules into an existing image should almost be an afterthought. Sure, people will *want* it, but I think these other properties might be more important.
-Mark (not even a real Squeaker) van Gulik
With all computer languages I have the problem that there is hardly any possibility for creating table structures. While C++ and pascal support things like matrix[x][y] and things like that and APL supports even more, I don't think they really solve what I would like. Even a case statement is very clumbsy in other languages, and is lacking in smalltalk.
Because smalltalk is the most flexible language, I would like to suggest that we could implement integrated spreadsheet support in Smalltalk. And use this facility to implement: 1) constant tables = flexibility 2) integer and floating-point calculations = speeeeed 3) block tables = case statement 4) data tables = database support 5) matrices = matrix & math support
It would be handy to create a table in your method and just say:
MyTable atCol:1 atRow:2 put: 5.5. MyTable update. "This recalculates the contents in the table" result:= MyTable atCol: 3 atRow: 2. ^result.
I have implemented my own spreadsheet in Pascal where I defined some positions as variables. MyTable:= { { "This" "is" "a" "Table" } { 0:input 3.14:pi =input*pi:angle =sin(angle):output } { 0 0 0 0 } { "traditionally:" { 0 3.14 =A5*B5 =sin(C5) } }
MyTable at: $input put: 5.5. MyTable update. result:= MyTable at: $output.
Or similar:
mode:= inputMode. pos:= MyTable find: mode inRange: searchRange. result:= MyTable at: (pos addRow:1).
Within the table, one might even connect with other tables. Or even databases... I have added a spreadsheet support to my own commercial application and it gives quite a difference. So I thought, why not have it in squeak too??
For now, it is just an idea, but that is how things start..
Greetings, Dirk
Dirk --
Playground, the language we used for the Vivarium project, was essentially an OO language whose objects were spreadsheet columns. The spreadsheet "method" was a condition-action pair that would cause a value to be put into the corresponding cell. We found this to be quite powerful for many situations, and it would be nice to have an easy way to do such programming in Squeak. (Of course, it is not difficult to program in that style now, just not really pretty.) BTW, Bob Arning did do the start of Spreadsheets in Squeak, and I think he put some examples on BSS.
Also, going way back in history, one of the first and most famous systems written in Smalltalk when it came out of Xerox PARC was the Analyst, essentially a big spreadsheet system in which each cell was MVC.
Cheers,
Alan
------
At 2:11 PM +0200 10/27/01, Dirk Wessels wrote:
With all computer languages I have the problem that there is hardly any possibility for creating table structures. While C++ and pascal support things like matrix[x][y] and things like that and APL supports even more, I don't think they really solve what I would like. Even a case statement is very clumbsy in other languages, and is lacking in smalltalk.
Because smalltalk is the most flexible language, I would like to suggest that we could implement integrated spreadsheet support in Smalltalk. And use this facility to implement:
- constant tables = flexibility
- integer and floating-point calculations = speeeeed
- block tables = case statement
- data tables = database support
- matrices = matrix & math support
It would be handy to create a table in your method and just say:
MyTable atCol:1 atRow:2 put: 5.5. MyTable update. "This recalculates the contents in the table" result:= MyTable atCol: 3 atRow: 2. ^result.
I have implemented my own spreadsheet in Pascal where I defined some positions as variables. MyTable:= { { "This" "is" "a" "Table" } { 0:input 3.14:pi =input*pi:angle =sin(angle):output } { 0 0 0 0 } { "traditionally:" { 0 3.14 =A5*B5 =sin(C5) } }
MyTable at: $input put: 5.5. MyTable update. result:= MyTable at: $output.
Or similar:
mode:= inputMode. pos:= MyTable find: mode inRange: searchRange. result:= MyTable at: (pos addRow:1).
Within the table, one might even connect with other tables. Or even databases... I have added a spreadsheet support to my own commercial application and it gives quite a difference. So I thought, why not have it in squeak too??
For now, it is just an idea, but that is how things start..
Greetings, Dirk
At 12:20 27.10.2001 -0800, Alan Kay wrote:
Also, going way back in history, one of the first and most famous systems written in Smalltalk when it came out of Xerox PARC was the Analyst, essentially a big spreadsheet system in which each cell was MVC.
Hmm, the marketing material I have here (for the XSIS product, V2.1 and 3.0) seems to suggest a broad spectrum, along the lines of "integrated application suite." Outliner, Business Charts, Forms, Databases, Maps, Spreadsheets, DTP, etc. An Expert System Shell (HUMBLE) thrown in for good measure. Management of security and access levels. Must have made The Customer quite happy.
BTW, the spreadsheet component ASP, the "Analytic Spreadsheet Package", has been described by Kurt Piersol in the OOPSLA 1986 proceedings, pp. 385--390.
HTH, Helge
Helge Horch Helge.Horch@munich.netsurf.de is widely believed to have written:
Hmm, the marketing material I have here (for the XSIS product, V2.1 and 3.0) seems to suggest a broad spectrum, along the lines of "integrated application suite." Outliner, Business Charts, Forms, Databases, Maps, Spreadsheets, DTP, etc. An Expert System Shell (HUMBLE) thrown in for good measure. Management of security and access levels. Must have made The Customer quite happy.
I used the Analyst a bit many years ago; in fact we (as in 'Smalltalk Express Ltd' a long defunct pioneering uk company I worked for many years ago) did a lot of work trying to get XSIS to let us sell it on the Acorn port of BrouHaHa I did. On a Tek 4405 it was amazingly snappy; all sorts of neat things were doable. Animated spreadsheet cells where the animation rate depended on some other cells, cells that were other spreadsheets or entire expert systems, all sorts of wonders. The most amazing part was Kurt claiming with a straight face that most of it took him a single summer to write.
I imagine we could do something very similar but with more colour and zap with Squeak. Of course, no one but us would care since it wouldn't be powerpoint/word/excel/access compatible. I'm sure we could however make a compatible flight simulator easter-egg in our spreadsheet :-)
tim
Three guesses as to who the first customer was ....
Cheers,
Alan
------
At 3:27 AM +0100 11/2/01, Helge Horch wrote:
At 12:20 27.10.2001 -0800, Alan Kay wrote:
Also, going way back in history, one of the first and most famous systems written in Smalltalk when it came out of Xerox PARC was the Analyst, essentially a big spreadsheet system in which each cell was MVC.
Hmm, the marketing material I have here (for the XSIS product, V2.1 and 3.0) seems to suggest a broad spectrum, along the lines of "integrated application suite." Outliner, Business Charts, Forms, Databases, Maps, Spreadsheets, DTP, etc. An Expert System Shell (HUMBLE) thrown in for good measure. Management of security and access levels. Must have made The Customer quite happy.
BTW, the spreadsheet component ASP, the "Analytic Spreadsheet Package", has been described by Kurt Piersol in the OOPSLA 1986 proceedings, pp. 385--390.
HTH, Helge
Ummmm.... let me see.... probably a big C.ompany and they would probably process lots of I.nformation and need to A.nalyze the info for implicit content...
Hmmmm, wonder who it may have been??? ;-}>
From: Alan Kay Alan.Kay@squeakland.org Reply-To: squeak-dev@lists.squeakfoundation.org Date: Fri, 2 Nov 2001 00:15:19 -0800 To: squeak-dev@lists.squeakfoundation.org Subject: Re: [ENH] New idea: Integrated spreadsheet support for Squeak
Three guesses as to who the first customer was ....
Cheers,
Alan
At 3:27 AM +0100 11/2/01, Helge Horch wrote:
At 12:20 27.10.2001 -0800, Alan Kay wrote:
Also, going way back in history, one of the first and most famous systems written in Smalltalk when it came out of Xerox PARC was the Analyst, essentially a big spreadsheet system in which each cell was MVC.
Hmm, the marketing material I have here (for the XSIS product, V2.1 and 3.0) seems to suggest a broad spectrum, along the lines of "integrated application suite." Outliner, Business Charts, Forms, Databases, Maps, Spreadsheets, DTP, etc. An Expert System Shell (HUMBLE) thrown in for good measure. Management of security and access levels. Must have made The Customer quite happy.
BTW, the spreadsheet component ASP, the "Analytic Spreadsheet Package", has been described by Kurt Piersol in the OOPSLA 1986 proceedings, pp. 385--390.
HTH, Helge
--
I've been working a bit with ModSqueak ( the latest release from Squeak Foundation, I believe ) and have started to notice a few things that appear out of whack. There appear to be several classes such as ClusterInstaller which have somehow escaped being assigned to any Module, not even Unmanaged. There are also methods such as Cluster>>installerClass ( which answers ClusterInstaller ) which appear to be unassigned to any module.
I noticed this because I am looking at porting ModSqueak into VisualWorks ( 3.x for now ). The interesting thing is that I would have noticed the absence of classes such as ClusterInstaller had Cluster>>installerClass existed in the code that I extracted from ModSqueak. As it is, I extracted the code based on the Packages and the class and method definitions found within. So, it seems that these things were perhaps defined outside of the module system. Assuming that these things really do belong in a ModSqueak module somewhere, is there a reccomended way for me to run a sanity check/repair? ( workspace that I used to file-out all packages is attached ).
BTW, I find myself thinking that there is probably a strongly Aspect-Oriented flavor to this whole business... I wonder what others with more AO ( or better yet AOPST ) knowledge might think about AOP & Modularity in Smalltalk. In this case, based on my very limited AOP exposure, it looks like the whole ClusterInstaller "Aspect" went missing somehow- it was quite cleanly missing, no trace whatsoever in the other code that it should have been there. I think in a way that this says both very positive and slightly negative things about ModSqueak- something went missing, but in a very complete and well-coordinated way ;^). The things that are missing are easily found in the regular System or RB browsers, btw.
Actually, there are other cases such as ClassInstaller where not all of its methods ( such as #validate ) are in the module system. Not sure whether these are hints about other "aspects" gone missing or perhaps some other slip.
Thanks!
- les
I haven't found a nice way yet to do a sanity check, but attached is a workspace doit that creates a dictionary mapping Class category names to names of classes within each category which do not appear to be a part of the Module system. In my case, there are quite a few, about 109 classes in dozens of categories, including some that look like they are part of ModSqueak itself. This map will at least give me some inroads towards identifying things that may be missing as I try to port the code over to VisualWorks. I'd be curious to find out if anyone else notices similar problems in ModSqueak, or if instead there is something that I've missed while getting it running.
- les
Once it gets going, a couple of simple invariants would seem to maintain sanity. Something like:
1. There is always an active module that changes are going to.
2. If you remove a module, you must also remove any parts of it that are installed in the system.
-Lex
I haven't found a nice way yet to do a sanity check, but attached is a = workspace doit that creates a dictionary mapping Class category names to = names of classes within each category which do not appear to be a part = of the Module system. In my case, there are quite a few, about 109 = classes in dozens of categories, including some that look like they are = part of ModSqueak itself. This map will at least give me some inroads = towards identifying things that may be missing as I try to port the code = over to VisualWorks. I'd be curious to find out if anyone else notices = similar problems in ModSqueak, or if instead there is something that = I've missed while getting it running.
----- Original Message ----- From: Mark van Gulik ghoul6@home.com To: squeak-dev@lists.squeakfoundation.org Sent: Saturday, October 27, 2001 2:27 AM Subject: Re: [ENH][Modules] Delta Modules [was: Another version]
Here's an idea: I think the idea of being able to manipulate and analyze modules *without* loading them is sufficiently important that the initial release of the module system should *not* actual support module loading.
That's how I started out with Oasis. Initially, just a buffer in which I could load code and then do some quick and dirty analysis on it. It is quite a bit more than that now. ( http://sabine.canis.uiuc.edu:8080/Oasis ).
Such a system will still be useful for *describing*, say, how to partition an image.
Yes- there are a number of things that I've built for Oasis before or am working on now to support just this sort of thing.
Come to think of it, the actual loading should be a completely separate, er, module. That way you can use it for directly assembling production images from makefiles (without ever running a single bytecode of that image).
Well, technically there is some truth to that. Smalltalk/X does something like this, and I think that AOS also does this. But there is more to the story than drawing lines in the image- the code that is there has to change as well. The deepest non-modularities in Sqeuak are basically human programming practices which are at odds with a nice clean decomposition. Tools can't change that- but they can make it more apparent, and perhaps provide a bit more firepower for certain operations.
You'll also have a nice *clean* structure (unfettered by the implementations of method dictionaries and symbols etc) with which to perform analysis. Actual loading of modules into an existing image should almost be an afterthought.
LIke Allen says, by the time the stuff has come back into the image, the hard work has been done.
Sure, people will *want* it, but I think these other properties might be more important.
Initially, yes- I'm very hesitant to commit to a particular approach without having had the time to propose, explore, and throw away several of them. I've been at it off and on for 5 years, so I'm very wary of quick-fix solutions, and in particular any proposals that start with the word "just". ( or "simplest thing that could possibly work"... lets define "simplest", "thing", "could" and "work" why don't we? ).
- les
I seem to have forgotten to unsubscribe and this thread caught my eye. Oh well. As a journo, my heart goes out not to developers but to users. So:
Among reasons for having modules two are obvious: + Facilitate distribution: Coders can release directly without reference to a central distributing authority. Users can shop around for the pieces they need.
+ Facilitate maintenance. Coders can amend their code without referring to a central maintaining authority. Users can upgrade modules incrementally during system life.
In practice, the two conflict. Users get caught in DLL hell. Microsoft are not entirely dumb, but they realised it too late because it is a scale effect. The redhat people noticed the issues in upgrading Linux and tried to fix them with the rpm database. It sold the distro, but ultimately didn't work, just pushed back the problem by about 2 years, and then scale effects caught up again, as soon as the number of sources for things increased. Nowadays, with all these systems, people do a few customisations, then throw away the fragments and re-install a whole new boxful of toys again. The reason for the frequent release of complete Linux systems, when Unix is inherently modular, has become the certification by the vendor of coherent behavior of the whole.
I urge you, when analyzing this issue to look at the fundamental ways in which all known approaches have failed. Solving your module problem now for the existing handful of knowledgeable and sophisticated Squeak users/developers may not be the same as solving it for a distribution which has made it out of the lab into the wild.
Edmund
----- Original Message ----- From: Edmund Ronald eronald@rome.polytechnique.fr To: squeak-dev@lists.squeakfoundation.org Sent: Monday, October 29, 2001 4:42 AM Subject: Re: [ENH][Modules] Delta Modules [was: Another version]
I seem to have forgotten to unsubscribe and this thread caught my eye. Oh well. As a journo, my heart goes out not to developers but to users. So:
Among reasons for having modules two are obvious:
Facilitate distribution: Coders can release directly without reference to a central distributing authority. Users can shop around for the pieces they need.
Facilitate maintenance. Coders can amend their code without referring to a central maintaining authority. Users can upgrade modules incrementally during system life.
In practice, the two conflict. Users get caught in DLL hell. Microsoft are not entirely dumb, but they realised it too late because it is a scale effect. The redhat people noticed the issues in upgrading Linux and tried to fix them with the rpm database. It sold the distro, but ultimately didn't work, just pushed back the problem by about 2 years, and then scale effects caught up again, as soon as the number of sources for things increased. Nowadays, with all these systems, people do a few customisations, then throw away the fragments and re-install a whole new boxful of toys again. The reason for the frequent release of complete Linux systems, when Unix is inherently modular, has become the certification by the vendor of coherent behavior of the whole.
Certification leads to a whole mess of issues, but one thing I thought would be important ( years ago, before I realized it would be a Hard Problem ) would be to come up with ways of decoupling inter-module dependencies... that is, I didn't want modules to know about the specific existence of particualar other modules, but they could be allowed to know what they *expected* about the components in other modules- much like the way we do not require Classes to know explicitly about which classes implement the methods they are sending, but we do hold the *expectation* that the objects we are interacting with will understand the messages we are sending them.
I urge you, when analyzing this issue to look at the fundamental ways in which all known approaches have failed. Solving your module problem now for the existing handful of knowledgeable and sophisticated Squeak users/developers may not be the same as solving it for a distribution which has made it out of the lab into the wild.
This is why I really like the idea of supporting the ability to rapidly develop, test, and dispose of various approaches to modularization- basically, the "weak" modularity approach, where the existing tools remain unmodified ie, browsers and system dictionary are not changed ). I've been plinking away at Oasis for 5 years, and this has not been a straightforward process at all. Even now, though I believe that I really understand this problem a lot better than I did back then, I am not ready to jump up and say "this right here is absolutely IT- the Real McCoy, the Solution you've been looking for".
Fortunately, I'm no longer the only one ( or so it has seemed ) interested in this. There are some really good contributions coming out, and we can start comparing notes. These days I am building additional tools for Oasis ( a message tracer, actually a subset of another already existing tool in Oasis ), and looking at integrating ModSqueak, SCAN, and something of my own which is intended to deal with the same problems that Collage should have been good for solving. I'm also looking at what it would take to get Oasis out of VisualWorks- actually, there are big chunks of it that can be moved easily- the only hard part is redoing the active components, not an issue if one focuses initially only on inert components ( Oasis started out with components, and I still have them ). So, finally, after a really long time, I am hoping to start sharing some of the stuff I've learned building Oasis with the rest of the Squeak community.
- les
Hi,
Well, I've read the 246 messages that I collected during the Great Modularity Debate (GMD) in addition to the info on various Swikis for ModSqueak/Ginsu (Joseph Pelrine and Stephane Ducasse), Oasis (Les Tyrrell), and Environments (Dan Ingalls and Henrik Gedenryd). And, I have probably missed a few things along the way.
As far as I can tell, Dan Ingalls wants to "distribute active Squeak content as projects on the Internet" which leads to "modularity of projects" which in turn leads to a "component architecture" for Squeak. Correct?
Other folks have noted the lack of any crisp definitions or consensus for terms like "project", "package", "module", "creation", or "component", much less terms like "component architecture", "component framework", or "component backplanes". Clemens Szyperski discusses many of these concepts at length in his book on Component Software, but I'm having a hard time correlating Szyperski's book with concepts and ideas discussed in the GMD.
Apparently, the general plan is to schlepp along and figure all of this out as we go. Oey veh!
As engineers, scientists, and programmers, we tend to view the world in terms of "projects". We are trained and educated in this manner. In fact, some real engineers live their entire lives as a string of interesting projects. <grin> Although I'm a computer engineer, I usually don't think in terms of projects.
Whenever I want to do something, I usually head off the the library, bookstore, or my basement bookcases, collect some books, and spread them out on my workspace which also includes pens, pencils, piles of papers, stickies, notepads, a computer, some hot tea, and a little music. While I work on each small task sequentially, I'm usually working upon a lot of different things at once. Sometimes, I even work off the coffee table in the living room or a lawn table on the deck in the back yard.
Books are my basic unit of information, knowledge, wisdom, and understanding. Most books typically consist of a title, table of contents, preface, introduction, a string of chapters, notes, and an index all bound between two hard (or soft) covers. A book can consist of several volumes. Sometimes books are divided into parts or sections. But basically, books are made up of a string of chapters. Books are collected into respositories called libraries where they are classified according to some rigorous scheme so mere mortals can easily find them. Squeak "projects" in Squeak 3.0 seem close to what I want in a book. There is even a construct called a BookMorph.
So, why on earth would I want to modularize a book? How does one modularize "Gone With The Wind", the Bible, "Lord Of The Rings" or the Iliad? Why would somebody want to do so? How would one do it even if they could?
I can just see myself going to a library to rummage around in bins full of "chapters" (modules?), trying to collect enough of these pieces that might help me with my work.
I thought that the primary purpose of Squeak was to create dynamic books that would reside in a hardware device called a DynaBook which could reach through to the Internet in order to access huge libraries of dynamic books all over the world. Instead, it sounds like folks are creating components for building projects that reside in a hardware device called a DynaProject. IMHO, a DynaBook and a DynaProject are not the same critter. No, not at all. Please, help me out here.
Cheers, Roger.....
PS: I also don't see how children have a ghost of a chance when it comes to manipulating components in any meaningful way when highly educated engineers and scientists are having trouble doing it. Likewise, Smalltalk may have been created with children in mind, but it takes highly educated proferssionals to use Smalltalk effectively. Likewise, my grandchild gives me lots of stuff to hang on my refrigerator door, but in no sense is this real, or serious, "art" or "literature", dynamic or otherwise.
PPS: To end this rant on a more positive note, I have no doubt that highly educated and/or talented people will be able to create dynamic books for "children of all ages", but this ain't kid's stuff. :-) So, let's get back to worrying about DynaBooks, rather than DynaProjects.
Imagine how much difficulty professional programmers had with objects before they were invented!
I don't think it's a very good idea to extrapolate about the future of computing or what people will be able to understand by looking at what today's professionals are struggling with. If you look at the last 30 years, quite a bit of the stuff that was invented for children (and that children could indeed learn) has gradually (and somewhat grudgingly) been adopted by the experts. (I.e. great fluency in something can be a terrible barrier to finding and doing in easier ways.)
Cheers,
Alan
-------
At 6:31 PM -0700 10/29/01, Roger Vossler wrote:
Hi,
Well, I've read the 246 messages that I collected during the Great Modularity Debate (GMD) in addition to the info on various Swikis for ModSqueak/Ginsu (Joseph Pelrine and Stephane Ducasse), Oasis (Les Tyrrell), and Environments (Dan Ingalls and Henrik Gedenryd). And, I have probably missed a few things along the way.
As far as I can tell, Dan Ingalls wants to "distribute active Squeak content as projects on the Internet" which leads to "modularity of projects" which in turn leads to a "component architecture" for Squeak. Correct?
Other folks have noted the lack of any crisp definitions or consensus for terms like "project", "package", "module", "creation", or "component", much less terms like "component architecture", "component framework", or "component backplanes". Clemens Szyperski discusses many of these concepts at length in his book on Component Software, but I'm having a hard time correlating Szyperski's book with concepts and ideas discussed in the GMD.
Apparently, the general plan is to schlepp along and figure all of this out as we go. Oey veh!
As engineers, scientists, and programmers, we tend to view the world in terms of "projects". We are trained and educated in this manner. In fact, some real engineers live their entire lives as a string of interesting projects. <grin> Although I'm a computer engineer, I usually don't think in terms of projects.
Whenever I want to do something, I usually head off the the library, bookstore, or my basement bookcases, collect some books, and spread them out on my workspace which also includes pens, pencils, piles of papers, stickies, notepads, a computer, some hot tea, and a little music. While I work on each small task sequentially, I'm usually working upon a lot of different things at once. Sometimes, I even work off the coffee table in the living room or a lawn table on the deck in the back yard.
Books are my basic unit of information, knowledge, wisdom, and understanding. Most books typically consist of a title, table of contents, preface, introduction, a string of chapters, notes, and an index all bound between two hard (or soft) covers. A book can consist of several volumes. Sometimes books are divided into parts or sections. But basically, books are made up of a string of chapters. Books are collected into respositories called libraries where they are classified according to some rigorous scheme so mere mortals can easily find them. Squeak "projects" in Squeak 3.0 seem close to what I want in a book. There is even a construct called a BookMorph.
So, why on earth would I want to modularize a book? How does one modularize "Gone With The Wind", the Bible, "Lord Of The Rings" or the Iliad? Why would somebody want to do so? How would one do it even if they could?
I can just see myself going to a library to rummage around in bins full of "chapters" (modules?), trying to collect enough of these pieces that might help me with my work.
I thought that the primary purpose of Squeak was to create dynamic books that would reside in a hardware device called a DynaBook which could reach through to the Internet in order to access huge libraries of dynamic books all over the world. Instead, it sounds like folks are creating components for building projects that reside in a hardware device called a DynaProject. IMHO, a DynaBook and a DynaProject are not the same critter. No, not at all. Please, help me out here.
Cheers, Roger.....
PS: I also don't see how children have a ghost of a chance when it comes to manipulating components in any meaningful way when highly educated engineers and scientists are having trouble doing it. Likewise, Smalltalk may have been created with children in mind, but it takes highly educated proferssionals to use Smalltalk effectively. Likewise, my grandchild gives me lots of stuff to hang on my refrigerator door, but in no sense is this real, or serious, "art" or "literature", dynamic or otherwise.
PPS: To end this rant on a more positive note, I have no doubt that highly educated and/or talented people will be able to create dynamic books for "children of all ages", but this ain't kid's stuff. :-) So, let's get back to worrying about DynaBooks, rather than DynaProjects.
On Monday, October 29, 2001, at 07:31 pm, Roger Vossler wrote: [...]
So, why on earth would I want to modularize a book? How does one modularize "Gone With The Wind", the Bible, "Lord Of The Rings" or the Iliad? Why would somebody want to do so? How would one do it even if they could?
I love to nitpick, so I'd like to point out that you picked two (that I know of) bad examples out of four. The Bible is a collection of unrelated letters, books, songs, etc. (if it were "assembled" today it would probably include tunes from TV jingles, soup can labels, and random phone book pages). Don't let the hilariously ironic name fool you. <Yikes -- I just had to teach OSX10.1's spell checker "ironic" <Double-yikes -- I had to teach it "Yikes"!>>.
Lord of the Rings is also a series of books, if I recall correctly (I don't know whether J.R.R.T. intended this, or if it was a publishing "artifact").
Lord of the Rings is also a series of books, if I recall correctly (I don't know whether J.R.R.T. intended this, or if it was a publishing "artifact").
It was written and intended to be read as a single story. The publishers thought that it would never sell, so they insisted that it be "modularized" into three "books", with separate titles.
Later, of course, it was published as a single volume, as Tolkien intended all along.
Andrew
On Mon, 29 Oct 2001, Mark van Gulik wrote:
On Monday, October 29, 2001, at 07:31 pm, Roger Vossler wrote: [...]
So, why on earth would I want to modularize a book? How does one modularize "Gone With The Wind", the Bible, "Lord Of The Rings" or the Iliad? Why would somebody want to do so? How would one do it even if they could?
I love to nitpick,
Me too.
Iliad and Gone with the wind seem easily "modularizable".
But also, all these are examples (losely speaking) of literary texts. Two, at least, are novels (the other two, roughly, are a compilations). Novels, although often serialized, split up, merged, are relatively unitary works.
Textbooks, anthologies, etc. often aren't. It's not uncommon to have a "course guide" in the intro to a textbook (i.e., for a first semenster undergrad course do 1,2,5-7, for a graduate advance, 1-13, plus 15, 17, 19 as interest determines). When making coursepacks, I've often very finely tune the selections (think of anthologies that abridge works in various ways).
Anyhoo....
Cheers, Bijan Parsia.
"Roger Vossler" rvossler@qwest.net wrote...
As far as I can tell, Dan Ingalls wants to "distribute active Squeak content as projects on the Internet" which leads to "modularity of projects" which in turn leads to a "component architecture" for Squeak. Correct?
Yes, that's pretty close -- and other people have other goals, too.
<...self-admitted rant mostly elided...>
So, why on earth would I want to modularize a book? How does one modularize "Gone With The Wind", the Bible, "Lord Of The Rings" or the Iliad? Why would somebody want to do so? How would one do it even if they could?
That's not what we're talking about. We don't want to cramp the style of the content at all. But you can bring "Gone with the Wind" home from the library, read it, return it, and there aren't pieces of it left around your house. That's not necessarily the case with Squeak content right now. We just want to make sure that if you browse some active Squeak content, and then go on to something else, that your system doesn't gradually fill up with garbage, or run into conflicts between simultaneously loaded material.
There's more, too, having to do with whether a given piece of Squeak content will run in a given system, and if it may require some optional facilities. This doesn't arise in the case of books which are complete, except for, eg, the language and printed encoding that you are assumed to have mastered. The analogous solution would be to ship all content with Squeak, but right now that looks costly in download time and disk space. Moreover, that kind of modularity by insulation can be a barrier to some of the possible synergy we hope to achieve by embedding the content in an active medium.
- Dan
Hi All I appreciate the effort that is put into resolving this problem but, I seriously suggest that you think more deeply into the consequences of using (or abusing) certain words (symbols, icons, totems ...), like "module". I believe we are all entitled to invent words (or the "future") if existing words don't express the meaning behind the thought. Mode , module .. do, already, have an exact enough meaning, within the context of Smalltalk, to expect the use of another expression. Might "rhubarb" be less confusing? Encarta mode: 1. manner or form .. http://dictionary.msn.com/find/entry.asp?refid=1861630701 module http://dictionary.msn.com/find/entry.asp?refid=1861630743
Mode is already pretty well entrenched in traditional Smalltalk ie Model, View, Controller. And in VisualWorks it is a child of class Object. In fact class Mode or Module is rightfully the parent of anything that exists and as such should be the parent of Object. Therein lies the clue to why you are all locked into "wordsmithing" your way out of the "Parent-Child/Anties-Uncles/Neighbours" paradox; flaaamme, flaaammme! Ciao Justin (unspellchecked)
----- Original Message ----- From: "Henrik Gedenryd" Henrik.Gedenryd@lucs.lu.se To: "Squeak list" squeak-dev@lists.squeakfoundation.org Sent: Friday, October 26, 2001 11:58 PM Subject: Re: [ENH][Modules] Projects vs Modules, was: Delta Modules
goran.hultgren@bluefish.se wrote:
Projects vs Modules
I have read the stuff on the Swiki and my naive view is this:
A Module is a published piece of code.
Right, an abstract (piece of a) program with no reference whatsoever to how it is represented, run, or anything. Effectively a sort-of-mathematical abstraction.
It is not a "binary deliverable". But you can download/load/activate them in your environment. I think it is good that they are not binary and I think it would be much harder to build such a system with the functionality that Henrik have put in there if they were binary. Being non binary also makes it possible to manipulate these things more easily. On the other hand the repository is a pluggable component so that we can have different kinds of repositorys. For example, we could have a repository implementation that uses ImageSegments or something to increase loading speed.
A Project is more of a published binary deliverable. It surely can/could contain one or more modules but it also contains live instances etc. It is in my eyes analogous to the "binary download" you see everywhere on the Internet - just click and go. Typically not used by developers when they need a module to use in their own project but more for Squeak endusers "surfing for content".
I would like to distinguish Projects from Components--a Component is a concrete representation of the code in a Module, that can be dynamically loaded and unloaded. (Components also imply dynamic hook-up and such, which is a much smaller problem in Smalltalk than in e.g. C++, which has no standard representation for program meta-objects. Smalltalk already has all/most of that.) So a Component = a Module or Modules as concretely represented in Squeak (class and compiledmethod objects, etc.).
A Project is more than just this.
A Project is more of a published binary deliverable. It surely can/could contain one or more modules but it also contains live instances etc.
I assume what you read was http://minnow.cc.gatech.edu/squeak/2058.
Importantly, Projects have contents, as in "content provider", not just code (but it may contain code). This is what you call live instances, and I think this is the essential difference between Projects and Components.
What projects really are today is kind of vague, but the best notion I've been able to come up with is "the kind of thing Alan wants kids to create with their DynaBooks". But Alan/SqC also seems to have frequently changed their mind about^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H refined the notion of what Projects are.
I proposed Creation as the best name I could come up with instead of Project, which is extraordinarily vague and generic for such a specific use, and gives poor hints to what this "thing" is and does. A Creation is a collection of "hand-made" objects that someone has created (with a nod to Koestler with the colored planes). See the above page for a discussion of this.
As I see it, as concepts, Components are layered on top of/incorporate Modules, and Creations extend Components to include hand-made objects. Eventually.
_____ a Creation ( ) ¨¨|¨¨ _____ Components ( ) * (0 or more) ¨¨|¨¨ _____ Module(s) ( ) + (1 or more) ¨¨¨¨¨
Example:
I write a cool Morphic game including classes for general animation. The code is composed of a Module representing the Game itself with 2 more general submodules for Animation and Sound. They are not really blessed to go into the "base image" so I put everything in "People/gh/CoolGame". Ok, I upload it all onto the virtual module server (more on that later) so that people easily can load this module.
Yes, this is enough if all your objects can be programmatically generated by your code.
But I also set up a Project where I start the Game up with a centered window and I also type in a todo-list in an open Workspace. Finally I smack in a nice looking background image and then publish the Project onto Bobs superswiki AND also to another superswiki in Sweden containing only Morphic games (just fantasy).
These are "hand-made" (ie. non-programmatically generated) objects, which code isn't sufficient for creating (without taking extreme measures). At least code isn't convenient for creating them. You need the ability to conveniently (distribute and) load _objects_. This is the added role I assign to Creations. I think Creation also implies this having to do with "hand-made" objects (vs. code-generated).
So, developers typically load the module to get to the code and perhaps reuse my Animation module or just check out how the game was done.
Right, just to get the code, Modules are enough. Components/image segments may be convenient (think the 1MB refactoring browser).
End users typically find the project and loads that - it probably is faster and they get a "just point and click" experience. They get the modules with the project, but that is just a bonus.
Right, this to get the non-code objects too.
In general, I think Repositories should be a general facility for conveniently storing and accessing anything Squeak-related, including e.g. Projects/Creations, so that you can just give a path to a Project, or help pages, or you personal preferences file, or whatever, and Squeak will be able to locate the files for you.
regards, Göran
So what we really need is for SqC to agree with this ;-)
Henrik
squeak-dev@lists.squeakfoundation.org
-
Alan Kay -
Andrew P. Black -
Bijan Parsia -
Dan Ingalls -
Dirk Wessels -
Edmund Ronald -
Helge Horch -
Henrik Gedenryd -
Justin Walsh -
Les Tyrrell -
Les Tyrrell -
Lex Spoon -
Mark van Gulik -
Roger Vossler -
Sarkela -
Stephen Pair -
Tim Rowledge