On Mon, May 9, 2011 at 12:23 PM, Nicolas Cellier <[hidden email]> wrote:
If you have a wonderful simplification, you can also try selling it to Heh, you know we actually had a nice exchange about that. The conclusion we landed on was "Cuis needs namespaces like a fish needs a bicycle." :) Since Cuis is about starting with Smalltalk-80, a system designed to be mastered by a single individual, and gradually deriving its essence, it's unclear that the advantages namespaces offer either justify the cognitive load involved in learning/using them, or the work involved in implementing them, within the context of the goals which drive Cuis.
Really namespaces are a solution to a social problem in my world: a feature many engineering managers will want to see in a technology before they will be convinced to approve the use of it. Yes of course, namespaces are also technically very nice, but you don't really get much value out of them for anything but selling the manager unless you're working on a large code base or with a large team (or both.)
That said! As Cuis gets smaller, it gets easier to approach working prototypes for things that require a lot of support throughout the kernel, because there's just less code surface there to have to modify in order to realize one's ideas, which makes Cuis is a fantastic platform on which to explore and experiment with stuff like this, and namespaces is something I'd definitely like to try there :) In fact, I do mean to load Environments up as soon as I get OmniBrowser working in Cuis.
...But back to Squeak. With the license clean, a fast VM, active/visible development, and the core of Squeak looking better and better all the time, this is really one of the last boxes that I have to check before I can start winning the argument that says, "you should think about using Squeak at _your_ company." This is exciting to me!
Nicolas Casey Ransberger |
In reply to this post by Casey Ransberger-2
> I could put a hamburger on my head, but I really don't want to do > that. Yeah, do it! Performance art! :) -C -- Craig Latta www.netjam.org/resume +31 06 2757 7177 + 1 415 287 3547 |
In reply to this post by Chris Muller-3
I do not have the skills or intelligence to be dev. But, I do know how to read and I read the thoughts posted on the list in the hope that I learn something. I would be one of the *silent* although I have no idea whether that group is the *majority*. When *contention* produces real *content*, I am thankful. When not, well, it's on to the next post for me.
cheers, ching On Tue, May 10, 2011 at 2:10 AM, Chris Muller <[hidden email]> wrote: Just to clarify, I am not against survey-style polling; in fact I am Well said, Chris. ++1
|
In reply to this post by Casey Ransberger-2
On Mon, May 9, 2011 at 12:23 PM, Nicolas Cellier <[hidden email]> wrote: Just to be a bit contentious before this completely degenerates into a love-fest :) I want to say about your main topic, namespaces, that while neat as a check-box, they are a non-issue in practice. I have worked on several of the largest Smalltalk applications out there, and they all managed to grow to where they were (huge, over 10,000 classes), and still being relatively manageable, without namespaces. Javascript is considered ugly, but it is one of the most succesful languages out there, without namespaces. Java, on the other hand, has namespaces and, while the language is successful, Java projects groan under their own weight over a certain size (faster than Smalltalk). I am afraid Newspeak's obsession with modularity also misses the point. Commercial Smalltalk (VA, VW, ObjectStudio) manages complexity by splitting things in two orthogonal ways: class hierarchy and applications/packages/class extensions. This works quite well and namespaces do not add anything useful here. The fabled problem of trying to import different projects with clashing names is an urban myth. Useful packages already have solved this cheaply with prefixes: RB, GS, ... I don't see anything wrong in calling my classes FMSomething instead of org.fm.Something VW pushed their shiny new namespaces implementation down their customers' throats, which slowed the system significantly (this was offset by Eliot's efforts in the VM around the same release, but we would have obviously preferred to have a net performance gain, not a wash). They "demo-ed" the namespaces by gratuitously splitting the core of their system in namespaces, while admitting themselves that this was not the best example/usecase. But the most important thing is that namespaces did not help our huge project in any way. And they would not have helped it grow faster/better, had they been there from the beginning. On the contrary, in a system that already has packages/application, namespaces are just a distraction. And, since you are after opinion polls, I will take the opportunity to give you my opinion of what is missing from Smalltalk: multiple inheritance and multimethods. Cheers, Florin |
You might check out Slate:) It's all about the multiple dispatch.
On Mon, May 9, 2011 at 8:11 PM, Florin Mateoc <[hidden email]> wrote:
-- Casey Ransberger |
In reply to this post by Florin Mateoc
On 2011/05/10 04:11, Florin Mateoc wrote:
> On 5/9/2011 6:32 PM, Casey Ransberger wrote: >> On Mon, May 9, 2011 at 12:23 PM, Nicolas Cellier >> <[hidden email] >> <mailto:[hidden email]>> wrote: >> >> If you have a wonderful simplification, you can also try selling it to >> Juan and have it adopted in Cuis. >> >> >> Heh, you know we actually had a nice exchange about that. The >> conclusion we landed on was "Cuis needs namespaces like a fish needs a >> bicycle." :) Since Cuis is about starting with Smalltalk-80, a system >> designed to be mastered by a single individual, and gradually deriving >> its essence, it's unclear that the advantages namespaces offer either >> justify the cognitive load involved in learning/using them, or the >> work involved in implementing them, within the context of the goals >> which drive Cuis. >> >> Really namespaces are a solution to a social problem in my world: a >> feature many engineering managers will want to see in a technology >> before they will be convinced to approve the use of it. Yes of course, >> namespaces are also technically very nice, but you don't really get >> much value out of them for anything but selling the manager unless >> you're working on a large code base or with a large team (or both.) >> >> That said! As Cuis gets smaller, it gets easier to approach working >> prototypes for things that require a lot of support throughout the >> kernel, because there's just less code surface there to have to modify >> in order to realize one's ideas, which makes Cuis is a fantastic >> platform on which to explore and experiment with stuff like this, and >> namespaces is something I'd definitely like to try there :) In fact, I >> do mean to load Environments up as soon as I get OmniBrowser working >> in Cuis. >> >> ...But back to Squeak. With the license clean, a fast VM, >> active/visible development, and the core of Squeak looking better and >> better all the time, this is really one of the last boxes that I have >> to check before I can start winning the argument that says, "you >> should think about using Squeak at _your_ company." This is exciting >> to me! >> >> Nicolas >> >> >> -- >> Casey Ransberger >> >> >> > > Just to be a bit contentious before this completely degenerates into a > love-fest :) > > I want to say about your main topic, namespaces, that while neat as a > check-box, they are a non-issue in practice. I have worked on several of > the largest Smalltalk applications out there, and they all managed to > grow to where they were (huge, over 10,000 classes), and still being > relatively manageable, without namespaces. Javascript is considered > ugly, but it is one of the most succesful languages out there, without > namespaces. Java, on the other hand, has namespaces and, while the > language is successful, Java projects groan under their own weight over > a certain size (faster than Smalltalk). I am afraid Newspeak's obsession > with modularity also misses the point. I agree with most of your post: I think namespaces themselves - a means for avoiding class name clashes - are trivially solvable in practice by prefixing. I'd be interested in hearing more about your Newspeak opinions. What point are they missing? What mistakes do you think they're making? frank > Commercial Smalltalk (VA, VW, ObjectStudio) manages complexity by > splitting things in two orthogonal ways: class hierarchy and > applications/packages/class extensions. This works quite well and > namespaces do not add anything useful here. The fabled problem of trying > to import different projects with clashing names is an urban myth. > Useful packages already have solved this cheaply with prefixes: RB, GS, > ... I don't see anything wrong in calling my classes FMSomething instead > of org.fm.Something > VW pushed their shiny new namespaces implementation down their > customers' throats, which slowed the system significantly (this was > offset by Eliot's efforts in the VM around the same release, but we > would have obviously preferred to have a net performance gain, not a > wash). They "demo-ed" the namespaces by gratuitously splitting the core > of their system in namespaces, while admitting themselves that this was > not the best example/usecase. But the most important thing is that > namespaces did not help our huge project in any way. And they would not > have helped it grow faster/better, had they been there from the > beginning. On the contrary, in a system that already has > packages/application, namespaces are just a distraction. > > And, since you are after opinion polls, I will take the opportunity to > give you my opinion of what is missing from Smalltalk: multiple > inheritance and multimethods. > > Cheers, > Florin > > > > |
In reply to this post by Casey Ransberger-2
On 2011/05/10 04:26, Casey Ransberger wrote:
> You might check out Slate:) It's all about the multiple dispatch. Don't forget to read Foote/Johnson/Noble's take at http://www.laputan.org/reflection/Foote-Johnson-Noble-ECOOP-2005.html. I'd _love_ to read the implementation, but I can't find it. This touches on another issue though. The thread's turning into a bit of "X is useless/unnecessary but I really want Y". Before we turn things into a kitchen sink it might be worthwhile teasing apart what we want, and include helping APIs instead of the things. For instance, multimethods. Foote/Johnson/Noble fiddle a bit with the Compiler (and tools) to implement multimethods/multiple dispatch as a sort've currying process. I'm just using this as an example, mind, with the hope that other people's "vital feature I simply must have" may be amenable to similar analysis. So FJN fiddle with the compiler. You can imagine that other people might also need to fiddle with the compiler, to add pattern matching, for instance. So perhaps instead of adding multimethods or pattern matching to trunk, we should add ways of modifying Compiler to trunk such that we can reasonably safely extend the system without stepping on each other's toes (through overrides, or whatever). frank > On Mon, May 9, 2011 at 8:11 PM, Florin Mateoc <[hidden email] > <mailto:[hidden email]>> wrote: > > On 5/9/2011 6:32 PM, Casey Ransberger wrote: >> On Mon, May 9, 2011 at 12:23 PM, Nicolas Cellier >> <[hidden email] >> <mailto:[hidden email]>> wrote: >> >> If you have a wonderful simplification, you can also try >> selling it to >> Juan and have it adopted in Cuis. >> >> >> Heh, you know we actually had a nice exchange about that. The >> conclusion we landed on was "Cuis needs namespaces like a fish >> needs a bicycle." :) Since Cuis is about starting with >> Smalltalk-80, a system designed to be mastered by a single >> individual, and gradually deriving its essence, it's unclear that >> the advantages namespaces offer either justify the cognitive load >> involved in learning/using them, or the work involved in >> implementing them, within the context of the goals which drive Cuis. >> >> Really namespaces are a solution to a social problem in my world: >> a feature many engineering managers will want to see in a >> technology before they will be convinced to approve the use of it. >> Yes of course, namespaces are also technically very nice, but you >> don't really get much value out of them for anything but selling >> the manager unless you're working on a large code base or with a >> large team (or both.) >> >> That said! As Cuis gets smaller, it gets easier to approach >> working prototypes for things that require a lot of support >> throughout the kernel, because there's just less code surface >> there to have to modify in order to realize one's ideas, which >> makes Cuis is a fantastic platform on which to explore and >> experiment with stuff like this, and namespaces is something I'd >> definitely like to try there :) In fact, I do mean to load >> Environments up as soon as I get OmniBrowser working in Cuis. >> >> ...But back to Squeak. With the license clean, a fast VM, >> active/visible development, and the core of Squeak looking better >> and better all the time, this is really one of the last boxes that >> I have to check before I can start winning the argument that says, >> "you should think about using Squeak at _your_ company." This is >> exciting to me! >> >> Nicolas >> >> >> -- >> Casey Ransberger >> >> >> > > Just to be a bit contentious before this completely degenerates into > a love-fest :) > > I want to say about your main topic, namespaces, that while neat as > a check-box, they are a non-issue in practice. I have worked on > several of the largest Smalltalk applications out there, and they > all managed to grow to where they were (huge, over 10,000 classes), > and still being relatively manageable, without namespaces. > Javascript is considered ugly, but it is one of the most succesful > languages out there, without namespaces. Java, on the other hand, > has namespaces and, while the language is successful, Java projects > groan under their own weight over a certain size (faster than > Smalltalk). I am afraid Newspeak's obsession with modularity also > misses the point. > Commercial Smalltalk (VA, VW, ObjectStudio) manages complexity by > splitting things in two orthogonal ways: class hierarchy and > applications/packages/class extensions. This works quite well and > namespaces do not add anything useful here. The fabled problem of > trying to import different projects with clashing names is an urban > myth. Useful packages already have solved this cheaply with > prefixes: RB, GS, ... I don't see anything wrong in calling my > classes FMSomething instead of org.fm.Something > VW pushed their shiny new namespaces implementation down their > customers' throats, which slowed the system significantly (this was > offset by Eliot's efforts in the VM around the same release, but we > would have obviously preferred to have a net performance gain, not a > wash). They "demo-ed" the namespaces by gratuitously splitting the > core of their system in namespaces, while admitting themselves that > this was not the best example/usecase. But the most important thing > is that namespaces did not help our huge project in any way. And > they would not have helped it grow faster/better, had they been > there from the beginning. On the contrary, in a system that already > has packages/application, namespaces are just a distraction. > > And, since you are after opinion polls, I will take the opportunity > to give you my opinion of what is missing from Smalltalk: multiple > inheritance and multimethods. > > Cheers, > Florin > > > > > > > -- > Casey Ransberger > > > > |
In reply to this post by Frank Shearar
On 5/10/2011 2:08 AM, Frank Shearar wrote:
> On 2011/05/10 04:11, Florin Mateoc wrote: >> Just to be a bit contentious before this completely degenerates into a >> love-fest :) >> >> I want to say about your main topic, namespaces, that while neat as a >> check-box, they are a non-issue in practice. I have worked on several of >> the largest Smalltalk applications out there, and they all managed to >> grow to where they were (huge, over 10,000 classes), and still being >> relatively manageable, without namespaces. Javascript is considered >> ugly, but it is one of the most succesful languages out there, without >> namespaces. Java, on the other hand, has namespaces and, while the >> language is successful, Java projects groan under their own weight over >> a certain size (faster than Smalltalk). I am afraid Newspeak's obsession >> with modularity also misses the point. > > I agree with most of your post: I think namespaces themselves - a means for avoiding class name clashes - are > trivially solvable in practice by prefixing. > > I'd be interested in hearing more about your Newspeak opinions. What point are they missing? What mistakes do you > think they're making? > > frank > Well, first you ask for my Newspeak opinions, then you follow up with another message warning that this thread is turning into something else :) In short, and related to what I already mentioned, I think there is great value in having the possibility to modify somebody else's code to suit your needs (this is also what open source is all about), but if you can, instead of directly changing the code in place, it is very helpful to keep your changes separate, mainly by extending their classes, or even better, in combination with overrides (and of course, in combination with inheritance) - overrides is one thing that VW did better than Envy, at least conceptually (the implementation had its hickups), and I think it is the natural successor to class extensions. I think that one cannot really future-proof their designs (not over what you can achieve already by writing clean/clear code, well organized in hierarchies and extensions), so it is the wrong choice to hamper useful activities (other people conveniently extending/modifying your implementation) for at best marginal improvements in manageability (or whatever else modularity brings). If I have nice concepts and tool support for extending/modifying imported packages, I can actually write less code and keep those modifications/extensions cleanly separated and better managed. Smalltalk is permissive, it does not forbid you to use modules (e.g. by using conventions). It also does not force you to use extensions if you dislike them. Furthermore, from reading what Gilad wrote about class extensions, I assume he has never worked with Envy or Store. Those are clearly not about monkey patching, or applying patches dynamically, or patching in general. In addition to being source control systems, class extensions in their contexts are a way to organize your code, which is orthogonal to the class hierarchy, and as such, it helps enormously to deal with complexity. One puts methods which are dealing with, say, XML representation, in an application called XML. These include extensions to Object, String, etc, and they help keeping class Object clean (at least as it is in its original package/application), not pollute it - of course, this assumes tool support, but the browsers are essentially the only place where we can talk bout pollution, nobody cares that at runtime the class has all those methods in its method dictionary. But extensions to base classes are by far the exception, not the rule. A large application, and its classes, deal with many different aspects, for which extensions are more appropriate than new classes. This is one of the reasons aspect oriented programming made sense in Java, which does not have extensions, but does not make a lot of sense in Smalltalk. And the thing is, you can add aspects to somebody else's projects as well, they could not have thought of everything possible or needed in advance. Just like with the image (I am not talking about Newspeak right now), so many people complain about image based development, but nobody stops them from loading everything fresh in some minimal core image every time they start working, yet nobody does it. Java is oh, so clean, it starts fresh from files - so why do people complain about startup times, when you have a huge application and you need to load and initialize thousands of classes every time you start it? The image model is not (really) forced upon us, we use it because we like it and it is convenient. It can probably be improved upon, here I am pretty much in agreement with what Gilad said, my point is that one should not take that useful capability away just because it allows you to do bad things. Florin |
In reply to this post by Nicolas Cellier
Independent of the current discussion, this is a nice description of how the current process works. Should be made into an FAQ item somewhere.
- Bert - On 09.05.2011, at 16:23, Nicolas Cellier wrote: > By now, the situation is the following (my understanding): > > The core developpers have commit right. > They shall do peer reviews on commits. > The core developpers are nominated by the board. > The board is elected by a community. > The community members are co-opted. > > Design decisions are discussed in squeak-dev. > Anyone can participate to the dicussion. > The final commit decision is in the hand of core developpers. > Until now, decisions are generally discussed before applied (apart > obvious fixes). > They are rather motivated and meet agreement among the peers > (at least, they meet no major disagreement). > > Anyone can submit a change in the inbox. > There is no guaranty that this change will be integrated or even considered > As mentionned earlier, the fastest way to integration is a good rationale. > The biggest the change is, the best the rationale should be. > > Anyone can submit an idea in squeak-dev. > However, please consider that an idea might be far from a solution. > You'll probably have to convince both programmers and commiters, and > make plans... > > As stated in an old thread, trunk has no global development plan. > Trunk is just a community of individuals with individual goals. > This configuration favours a certain conservatism. > This is seen as an advantage for maintaining existing applications. > Introduction of pragmatic little changes is rather fast and welcomed in trunk. > Generally, the trunk is not doing bad wrt continuous integration. > > On the other side, introduction of major changes certainly is restrained. > IMO, integration of major changes can happen if these changes: > - are ready to integrate > - either simplify a framework or extend functionalities significantly > - don't gratuitously ruin compatibility with a bunch of usefull packages > - are elegant, simple, not over-engineered > > I think Pharo is somehow complementary: > less conservatism and less restrictions about API changes. > Pharo has written goals (and certainly some unwritten too) and > priorities (kind of plan). > So if you have revolutionary solutions matching one of the goals > (written or unwritten), you might knock at Pharo's door. > However, neither is Pharo a democracy. > > If you have a wonderful simplification, you can also try selling it to > Juan and have it adopted in Cuis. > Neither a democracy. > > Well, having a choice among several dictatorships already is a start > of democracy ;) > That said, current model is not written in stone and can evolve. > It should evolve if it fails to find resources to survive. > IMO the board should drive these evolutions. > Anyone can ask for though and you're welcome. > > Nicolas |
In reply to this post by Florin Mateoc
Great post! Thanks for writing. You made some points well that I was struggling to express, so thank you. I really need to take some time to look at Newspeak soon.
On May 10, 2011, at 1:12 PM, Florin Mateoc <[hidden email]> wrote: > On 5/10/2011 2:08 AM, Frank Shearar wrote: >> On 2011/05/10 04:11, Florin Mateoc wrote: >>> Just to be a bit contentious before this completely degenerates into a >>> love-fest :) >>> >>> I want to say about your main topic, namespaces, that while neat as a >>> check-box, they are a non-issue in practice. I have worked on several of >>> the largest Smalltalk applications out there, and they all managed to >>> grow to where they were (huge, over 10,000 classes), and still being >>> relatively manageable, without namespaces. Javascript is considered >>> ugly, but it is one of the most succesful languages out there, without >>> namespaces. Java, on the other hand, has namespaces and, while the >>> language is successful, Java projects groan under their own weight over >>> a certain size (faster than Smalltalk). I am afraid Newspeak's obsession >>> with modularity also misses the point. >> >> I agree with most of your post: I think namespaces themselves - a means for avoiding class name clashes - are >> trivially solvable in practice by prefixing. >> >> I'd be interested in hearing more about your Newspeak opinions. What point are they missing? What mistakes do you >> think they're making? >> >> frank >> > > > Well, first you ask for my Newspeak opinions, then you follow up with another message warning that this thread is > turning into something else :) > > In short, and related to what I already mentioned, I think there is great value in having the possibility to modify > somebody else's code to suit your needs (this is also what open source is all about), but if you can, instead of > directly changing the code in place, it is very helpful to keep your changes separate, mainly by extending their > classes, or even better, in combination with overrides (and of course, in combination with inheritance) - overrides is > one thing that VW did better than Envy, at least conceptually (the implementation had its hickups), and I think it is > the natural successor to class extensions. > I think that one cannot really future-proof their designs (not over what you can achieve already by writing clean/clear > code, well organized in hierarchies and extensions), so it is the wrong choice to hamper useful activities (other people > conveniently extending/modifying your implementation) for at best marginal improvements in manageability (or whatever > else modularity brings). If I have nice concepts and tool support for extending/modifying imported packages, I can > actually write less code and keep those modifications/extensions cleanly separated and better managed. > Smalltalk is permissive, it does not forbid you to use modules (e.g. by using conventions). It also does not force you > to use extensions if you dislike them. > > Furthermore, from reading what Gilad wrote about class extensions, I assume he has never worked with Envy or Store. > Those are clearly not about monkey patching, or applying patches dynamically, or patching in general. In addition to > being source control systems, class extensions in their contexts are a way to organize your code, which is orthogonal to > the class hierarchy, and as such, it helps enormously to deal with complexity. One puts methods which are dealing with, > say, XML representation, in an application called XML. These include extensions to Object, String, etc, and they help > keeping class Object clean (at least as it is in its original package/application), not pollute it - of course, this > assumes tool support, but the browsers are essentially the only place where we can talk bout pollution, nobody cares > that at runtime the class has all those methods in its method dictionary. But extensions to base classes are by far the > exception, not the rule. A large application, and its classes, deal with many different aspects, for which extensions > are more appropriate than new classes. This is one of the reasons aspect oriented programming made sense in Java, which > does not have extensions, but does not make a lot of sense in Smalltalk. And the thing is, you can add aspects to > somebody else's projects as well, they could not have thought of everything possible or needed in advance. > > Just like with the image (I am not talking about Newspeak right now), so many people complain about image based > development, but nobody stops them from loading everything fresh in some minimal core image every time they start > working, yet nobody does it. Java is oh, so clean, it starts fresh from files - so why do people complain about startup > times, when you have a huge application and you need to load and initialize thousands of classes every time you start > it? The image model is not (really) forced upon us, we use it because we like it and it is convenient. It can probably > be improved upon, here I am pretty much in agreement with what Gilad said, my point is that one should not take that > useful capability away just because it allows you to do bad things. > > Florin > |
In reply to this post by Florin Mateoc
2011/5/10 Florin Mateoc <[hidden email]>:
> On 5/10/2011 2:08 AM, Frank Shearar wrote: >> On 2011/05/10 04:11, Florin Mateoc wrote: >>> Just to be a bit contentious before this completely degenerates into a >>> love-fest :) >>> >>> I want to say about your main topic, namespaces, that while neat as a >>> check-box, they are a non-issue in practice. I have worked on several of >>> the largest Smalltalk applications out there, and they all managed to >>> grow to where they were (huge, over 10,000 classes), and still being >>> relatively manageable, without namespaces. Javascript is considered >>> ugly, but it is one of the most succesful languages out there, without >>> namespaces. Java, on the other hand, has namespaces and, while the >>> language is successful, Java projects groan under their own weight over >>> a certain size (faster than Smalltalk). I am afraid Newspeak's obsession >>> with modularity also misses the point. >> >> I agree with most of your post: I think namespaces themselves - a means for avoiding class name clashes - are >> trivially solvable in practice by prefixing. >> >> I'd be interested in hearing more about your Newspeak opinions. What point are they missing? What mistakes do you >> think they're making? >> >> frank >> > > > Well, first you ask for my Newspeak opinions, then you follow up with another message warning that this thread is > turning into something else :) > > In short, and related to what I already mentioned, I think there is great value in having the possibility to modify > somebody else's code to suit your needs (this is also what open source is all about), but if you can, instead of > directly changing the code in place, it is very helpful to keep your changes separate, mainly by extending their > classes, or even better, in combination with overrides (and of course, in combination with inheritance) - overrides is > one thing that VW did better than Envy, at least conceptually (the implementation had its hickups), and I think it is > the natural successor to class extensions. > I think that one cannot really future-proof their designs (not over what you can achieve already by writing clean/clear > code, well organized in hierarchies and extensions), so it is the wrong choice to hamper useful activities (other people > conveniently extending/modifying your implementation) for at best marginal improvements in manageability (or whatever > else modularity brings). If I have nice concepts and tool support for extending/modifying imported packages, I can > actually write less code and keep those modifications/extensions cleanly separated and better managed. > Smalltalk is permissive, it does not forbid you to use modules (e.g. by using conventions). It also does not force you > to use extensions if you dislike them. > > Furthermore, from reading what Gilad wrote about class extensions, I assume he has never worked with Envy or Store. > Those are clearly not about monkey patching, or applying patches dynamically, or patching in general. In addition to > being source control systems, class extensions in their contexts are a way to organize your code, which is orthogonal to > the class hierarchy, and as such, it helps enormously to deal with complexity. One puts methods which are dealing with, > say, XML representation, in an application called XML. These include extensions to Object, String, etc, and they help > keeping class Object clean (at least as it is in its original package/application), not pollute it - of course, this > assumes tool support, but the browsers are essentially the only place where we can talk bout pollution, nobody cares > that at runtime the class has all those methods in its method dictionary. But extensions to base classes are by far the > exception, not the rule. A large application, and its classes, deal with many different aspects, for which extensions > are more appropriate than new classes. This is one of the reasons aspect oriented programming made sense in Java, which > does not have extensions, but does not make a lot of sense in Smalltalk. And the thing is, you can add aspects to > somebody else's projects as well, they could not have thought of everything possible or needed in advance. > > Just like with the image (I am not talking about Newspeak right now), so many people complain about image based > development, but nobody stops them from loading everything fresh in some minimal core image every time they start > working, yet nobody does it. Java is oh, so clean, it starts fresh from files - so why do people complain about startup > times, when you have a huge application and you need to load and initialize thousands of classes every time you start > it? The image model is not (really) forced upon us, we use it because we like it and it is convenient. It can probably > be improved upon, here I am pretty much in agreement with what Gilad said, my point is that one should not take that > useful capability away just because it allows you to do bad things. > > Florin > > Maybe Newspeak utility is at another level: like replacing an OS/Navigator and having applications co-existing in peace. like having untrusted downloaded applications running in secure environments. Nicolas |
In reply to this post by Casey Ransberger-2
Casey Ransberger wrote on Mon, 9 May 2011 13:40:14 -0700
> * I called it a "silent majority" because my gut says there's a Pareto > effect going on, and probably 20% or less of us actually post. I have > no proof nor a count of the readers on squeak-dev. I shouldn't have > made a statement like that without having some numbers to attach > to it. I screwed up here too. Totally my fault. Since I use Celeste to read this mailing list, it was easy enough to find that 315 unique email addresses sent messages here since May 12, 2010. A quick inspection showed that a few people used more than one address, but this is a good approximation to the number of posters. At the squeakfoundation site we can see that this list has 1264 non digested subscribers plus 324 digested subscribers, so less than 20% of the people who read these messages post here, exactly as you had guessed. -- Jecel |
Free forum by Nabble | Edit this page |