Resolution of Contentious Issues

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Resolution of Contentious Issues

Casey Ransberger-2
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
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


Reply | Threaded
Open this post in threaded view
|

Re: Resolution of Contentious Issues

ccrraaiigg
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




Reply | Threaded
Open this post in threaded view
|

Re: Resolution of Contentious Issues

ching
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
greatly interested in counting.  However, the way this was presented,
as a "resolution of contentious issues," while at the same time,
itself, being contentious with divisive, comparative language; that
approach will not be effective to garner my support.

I would only participate if I were sure the poll would not serve as a
wedge to divide our community / communities.

However, maybe not, because perhaps the emergent phenomena of "no
consensus" should be viewed _as_ a consensus; that the proposal could
not pass muster with enough of the bright minds here for action to be
warranted and, therefore, the choice not do do it was and is the
correct one.
Well said, Chris.
++1
 

 - Chris



On Mon, May 9, 2011 at 10:52 AM, Chris Muller <[hidden email]> wrote:
> Casey,
>
>> I've seen a few rounds of discussion around contentious issues. Namespaces
>> are a fantastic example. Some of these issues, (I'll call them Oddballs,)
>> just don't like getting resolved. The pattern is that almost everyone who
>> speaks out has a different idea about how to #doIt. The conversation usually
>> goes in a long circle, and then gets garbage collected when everyone gets
>> too fatigued with the debate to continue it.
>
> Vigorous debate is not only normal, but essential, for a successful
> software development community.
>
>> I often wonder what the silent majority think about Oddball issues. We
>
> Did the "silent majority" have a silent vote, and that's how you know
> they were the "majority" of something?
>
>> I'm thinking of this in part after a conversation that happened at the first
>> SSUG meeting. We talked about how we tend to argue in circles in squeak-dev,
>
> We "tend to argue in circles" in squeak-dev.  That's ridiculous.
>
>> while the Pharo folk set up a "working group" to make decisions about stuff
>
> They do?  I searched the Pharo list for "working group" but did not
> find any announcements.  Can you tell us more?  Who are they, what did
> they work on, and what was the final "solution"?
>
> As for Squeak, squeak-dev _is_ the working group.
>
>> like this, and then as a result get to make progress, even on issues which
>
> "Progress?"  That's a very subjective term..
>
>> are contentious in their community. I don't know if we actually need or want
>> a "working group," whatever that is, but it would be nice to _have a pulse
>> on the desires of the broader Squeak community._
>
> I would say, if the pulse isn't clear, this is the place to find it.
> You can poll here, our community is small enough to be able to do that
> by just reading the responses of the folks who care enough to voice
> their opinion.  The "silent majority" has no voice other than their
> code, which must be good enough to lure our community into change.
>
>> two problems a) contention, and b) no workable implementation, it would be
>> nice to get some of the contention out of the way so that I can quit arguing
>> on a mailing list and #doIt.
>
> I think you know, there's plenty to work on that requires no arguing.  :)
>
>  - Chris
>




Reply | Threaded
Open this post in threaded view
|

Re: Resolution of Contentious Issues

Florin Mateoc
In reply to this post by Casey Ransberger-2
On 5/9/2011 6:32 PM, Casey Ransberger wrote:
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
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


Reply | Threaded
Open this post in threaded view
|

Re: Resolution of Contentious Issues

Casey Ransberger-2
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:
On 5/9/2011 6:32 PM, Casey Ransberger wrote:
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
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


Reply | Threaded
Open this post in threaded view
|

Re: Resolution of Contentious Issues

Frank Shearar
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
>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Things We Must Have (Re: [squeak-dev] Resolution of Contentious Issues)

Frank Shearar
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
>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Resolution of Contentious Issues

Florin Mateoc
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

Reply | Threaded
Open this post in threaded view
|

Re: Resolution of Contentious Issues

Bert Freudenberg
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


Reply | Threaded
Open this post in threaded view
|

Re: Resolution of Contentious Issues

Casey Ransberger-2
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
>

Reply | Threaded
Open this post in threaded view
|

Re: Resolution of Contentious Issues

Nicolas Cellier
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

Reply | Threaded
Open this post in threaded view
|

list stats (was: Resolution of Contentious Issues)

Jecel Assumpcao Jr
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


12