I disagree as I also disagree with the replacement of workspace and the inspector. My opinion on this can be summarised as "*Nothing should be added to Pharo without being fully documented*" . The use of workspace and the inspector is well documented in PBE. There is no official documentation for GTPlayground and GTInspector. Sure those tools are not as powerful as the tools you guys have developed but they are production ready, well tested and fully documented. But I know of course that my opinion is not popular since pharoers care more about extending their environment than caring about newcomers or teaching people how to use Pharo. This is a trend that has dominated Pharo and it looks it will continue and takes Pharo a direction I definetly dont want to go. On the other hand Pharo is the only tool and language that does this at least compared to my experience. On Mon, Dec 8, 2014 at 10:47 AM, phil@highoctane.be <phil@highoctane.be> wrote:

This makes a lot of sense.

Having a plain workspace alongside would be perfect for me.

I am using Playground in my 3.0 (now having installed the new version with the nicer menus) and it works well. But this is definitely not what I use as a workspace.

One use case for a plain Workspace is when providing a kind of list of sample commands to customers to use on the image.

Like in: "Open this workspace contents, here are the typical commands for you to use".

Removing this ability and having a large thing popping at the right is really disturbing for these use cases.

Phil

On Mon, Dec 8, 2014 at 7:18 AM, Tudor Girba <tudor@tudorgirba.com> wrote:

...

Hi,

As you might see, the GTPlayground is called playground not workspace. The main reason for this is that workspace implies the place where work is done, and work is typically associated with creating code.

This is not the intention of the workspace.

Workspace also comes with a history that is associated with actual implementations. While the current GTPlayground might appear to be similar to the workspace, I think the way you can use the latter produces a significant shift.

Furthermore, I think the term playground is more inline with the idea of "playing with live objects". And, in the future, the implementation will likely evolve towards even more liveliness.

It is for this reason that I would prefer that the World menu item gets renamed to Playground.

What do you think?

Cheers, Doru

-- www.tudorgirba.com

"Every thing has its own flow"

Hi Kilon, I agree with you in saying that we should have documentation. But, those tools are already added. And they are documented on the humane-assessment.com blog, and this can serve as a strong basis for a more official documentation. Please keep in mind that Pharo 4.0 is still under development, and things will still change until the release. And, of course, we would welcome anyone willing to contribute with documentation. Cheers, Doru On Mon, Dec 8, 2014 at 10:27 AM, kilon alios <kilon.alios@gmail.com> wrote:

I disagree as I also disagree with the replacement of workspace and the inspector.

My opinion on this can be summarised as "*Nothing should be added to Pharo without being fully documented*" .

The use of workspace and the inspector is well documented in PBE. There is no official documentation for GTPlayground and GTInspector. Sure those tools are not as powerful as the tools you guys have developed but they are production ready, well tested and fully documented.

But I know of course that my opinion is not popular since pharoers care more about extending their environment than caring about newcomers or teaching people how to use Pharo. This is a trend that has dominated Pharo and it looks it will continue and takes Pharo a direction I definetly dont want to go. On the other hand Pharo is the only tool and language that does this at least compared to my experience.

On Mon, Dec 8, 2014 at 10:47 AM, phil@highoctane.be <phil@highoctane.be> wrote:

...

This makes a lot of sense.

Having a plain workspace alongside would be perfect for me.

I am using Playground in my 3.0 (now having installed the new version with the nicer menus) and it works well. But this is definitely not what I use as a workspace.

One use case for a plain Workspace is when providing a kind of list of sample commands to customers to use on the image.

Like in: "Open this workspace contents, here are the typical commands for you to use".

Removing this ability and having a large thing popping at the right is really disturbing for these use cases.

Phil

On Mon, Dec 8, 2014 at 7:18 AM, Tudor Girba <tudor@tudorgirba.com> wrote:

...

Hi,

As you might see, the GTPlayground is called playground not workspace. The main reason for this is that workspace implies the place where work is done, and work is typically associated with creating code.

This is not the intention of the workspace.

Workspace also comes with a history that is associated with actual implementations. While the current GTPlayground might appear to be similar to the workspace, I think the way you can use the latter produces a significant shift.

Furthermore, I think the term playground is more inline with the idea of "playing with live objects". And, in the future, the implementation will likely evolve towards even more liveliness.

It is for this reason that I would prefer that the World menu item gets renamed to Playground.

What do you think?

Cheers, Doru

-- www.tudorgirba.com

"Every thing has its own flow"

-- www.tudorgirba.com "Every thing has its own flow"

"But, those tools are already added. And they are documented on the humane-assessment.com blog, and this can serve as a strong basis for a more official documentation." my issue is not "when" but "whether" . If you want to wait out the release of Pharo 4 to make official documentation, thats fine by me . I take late documentation over no documentation, any day. The problem I see with Pharo and one factor I feel it may even lead to the demise of Pharo as a project is that we see new and very exciting sfuff added to Pharo like your tools, but the documentation part is lackaster to say the least. The real problem comes when the original author decides to abandon or not further develop his tools it becomes extremely difficult for new people to come in and contribute. The very fact that now we replace the old workspace with a new tool is the testament to this problem. I think the situation would be dramatically different if Worskpace was fully documented, both at the user level and developer level. Its afterall an extremely important tool for Pharo. If that was the case we would have seen a natural evolution of workspace which would have made Playground far less needed. So its not that I disagree just with you I disagree with the general management of Pharo that follows the mentality "let the new features in and we worry about the documentation later on". No , no and NO! I was recently asked by a newcomer to Pharo being a python developer himself whether he should invest in Pharo . He wanted my opinion because I have experience both in python and pharo . I was not suprised to find out that he struggled with the documentation and he was really reluctant to give Pharo a serious try. He loved the features and all that but his learning was a much bigger pain than his experience with python and other programming languages. I ended up recommending him to ask more question here in the mailing list and he replied he did not feel comfortable asking question that for him were "stupid". Can I blame him ? Of course not. He was not aware of many of the blog posts and other source of documentation that are not "official". Dont know who that person is and how important as a member would become for the Pharo community but I can clearly see his problems being common to anyone or almost anyone introduced to Pharo unless that person comes already with a Smalltalk background. What I do know is Pharo needs new people to come in and take it further and in order to do that we need to build a Pharo that is as inviting to newcomers as our abilities permits us to. Putting documentation as a second priority is a recipe to disaster.

Hi Kilon, Please, let's get positive :). I really do not see how your remarks apply to the current situation. We put quite some effort in documenting GT tools through posts on the humane assessment blog (in the meantime, the page should be more reliable - I hope) and through examples in the image. We took specific care exactly in providing examples so that people can have something to guide themselves by. In fact, we did not release until we had those examples. Just look at the announcement of Spotter and you will see that it has a significant usage documentation. If it's not enough or not in the right place, you have to get specific and we can address those problems, but you cannot say that there is no documentation because that is simply not true. I think we have enough material to create a couple of chapters in a Pharo book, or even a book on its own, and I think it is reasonable to assume that given that the material is available we can find the rest of the effort to produce the "official" documentation. Cheers, Doru On Mon, Dec 8, 2014 at 1:56 PM, kilon alios <kilon.alios@gmail.com> wrote:

"But, those tools are already added. And they are documented on the humane-assessment.com blog, and this can serve as a strong basis for a more official documentation."

my issue is not "when" but "whether" . If you want to wait out the release of Pharo 4 to make official documentation, thats fine by me . I take late documentation over no documentation, any day.

The problem I see with Pharo and one factor I feel it may even lead to the demise of Pharo as a project is that we see new and very exciting sfuff added to Pharo like your tools, but the documentation part is lackaster to say the least. The real problem comes when the original author decides to abandon or not further develop his tools it becomes extremely difficult for new people to come in and contribute. The very fact that now we replace the old workspace with a new tool is the testament to this problem. I think the situation would be dramatically different if Worskpace was fully documented, both at the user level and developer level. Its afterall an extremely important tool for Pharo. If that was the case we would have seen a natural evolution of workspace which would have made Playground far less needed.

So its not that I disagree just with you I disagree with the general management of Pharo that follows the mentality "let the new features in and we worry about the documentation later on". No , no and NO!

I was recently asked by a newcomer to Pharo being a python developer himself whether he should invest in Pharo . He wanted my opinion because I have experience both in python and pharo . I was not suprised to find out that he struggled with the documentation and he was really reluctant to give Pharo a serious try. He loved the features and all that but his learning was a much bigger pain than his experience with python and other programming languages. I ended up recommending him to ask more question here in the mailing list and he replied he did not feel comfortable asking question that for him were "stupid". Can I blame him ? Of course not. He was not aware of many of the blog posts and other source of documentation that are not "official".

Dont know who that person is and how important as a member would become for the Pharo community but I can clearly see his problems being common to anyone or almost anyone introduced to Pharo unless that person comes already with a Smalltalk background.

What I do know is Pharo needs new people to come in and take it further and in order to do that we need to build a Pharo that is as inviting to newcomers as our abilities permits us to. Putting documentation as a second priority is a recipe to disaster.

-- www.tudorgirba.com "Every thing has its own flow"

+1 And there is plenty of blog post to turn them into chapters. If everything we produce would have this documentation quality I would not be worried. Le 8/12/14 05:33, Sven Van Caekenberghe a écrit :

More documentation is always better, but you can hardly accuse Doru from trying, he is making an excellent effort in explaining what he does and why, this is a lot of work, and I appreciate it very much. Note that he is also trying to convince others of alternative/new/experimental ideas, which is even harder.

And apart from that, he (and his team) are not just talking, they write actual working code and make it available. Of course they get all sorts of feedback, that is why they do it, but please, please consider the amount of work and determination it costs to make all this real/useable and not just vapourware !

I have the utmost respect for what they are doing and how they are doing it.

You (and other users) have a choice: you can keep using Pharo 3 and the tools there instead of going along with the development branch. Pharo 3 is meant for stable production use, it matches most of the current publications.

There is pharo-users@lists.pharo.org for normal beginner discussions, most users should ask questions there, not the other way around as it is today. I read both and try to help anyone the best I can.

Sven

...

On 08 Dec 2014, at 13:56, kilon alios <kilon.alios@gmail.com> wrote:

"But, those tools are already added. And they are documented on the humane-assessment.com blog, and this can serve as a strong basis for a more official documentation."

my issue is not "when" but "whether" . If you want to wait out the release of Pharo 4 to make official documentation, thats fine by me . I take late documentation over no documentation, any day.

The problem I see with Pharo and one factor I feel it may even lead to the demise of Pharo as a project is that we see new and very exciting sfuff added to Pharo like your tools, but the documentation part is lackaster to say the least. The real problem comes when the original author decides to abandon or not further develop his tools it becomes extremely difficult for new people to come in and contribute. The very fact that now we replace the old workspace with a new tool is the testament to this problem. I think the situation would be dramatically different if Worskpace was fully documented, both at the user level and developer level. Its afterall an extremely important tool for Pharo. If that was the case we would have seen a natural evolution of workspace which would have made Playground far less needed.

So its not that I disagree just with you I disagree with the general management of Pharo that follows the mentality "let the new features in and we worry about the documentation later on". No , no and NO!

I was recently asked by a newcomer to Pharo being a python developer himself whether he should invest in Pharo . He wanted my opinion because I have experience both in python and pharo . I was not suprised to find out that he struggled with the documentation and he was really reluctant to give Pharo a serious try. He loved the features and all that but his learning was a much bigger pain than his experience with python and other programming languages. I ended up recommending him to ask more question here in the mailing list and he replied he did not feel comfortable asking question that for him were "stupid". Can I blame him ? Of course not. He was not aware of many of the blog posts and other source of documentation that are not "official".

Dont know who that person is and how important as a member would become for the Pharo community but I can clearly see his problems being common to anyone or almost anyone introduced to Pharo unless that person comes already with a Smalltalk background.

What I do know is Pharo needs new people to come in and take it further and in order to do that we need to build a Pharo that is as inviting to newcomers as our abilities permits us to. Putting documentation as a second priority is a recipe to disaster.

Ok… several things :) First, I want to say that in this special case I tend to be in agreement with Torsten. Because I also see playground as an evolution of the good old workspace. Also, most documentation still refers to that area as “workspace” and not “playground”… and honestly I still do not understand why is *fundamentally* different. Inspectors are also really different and nevertheless we are still calling them inspectors… I suppose we can do the same with playground/workspace. Second, while I understand people tend to react conservative to changes, please guys understand that to keep tools inside image forever just does not scales and then requirements like “ok for adding, but please let the old tools too” can not be a path to follow. Of course we are not going to remove immediately, but certainly during next cycle one of both will fade away. It has to be like that because to maintain everything forever requires exponential resources… and we cannot do that. Third, documentation is important but hard to produce in a reliable way. Also, documentation style in pharo (or any smalltalk) is fundamentally different than documentation in other systems. We have a system and a culture that empowers system exploration and that is the way we need to improve things: more examples *in system* is better than written documentation (and we have several books now of written documentation, is just that some of them is outdated). And yes, we still need to improve a lot in that area… but we are not in zero, quite the opposite… anyway, we will never have the kind of documentation that other system has… Finally, fourth… we as a community has this tendency of start talking of A and end talking of Z. Like this thread… this was a question about the name of a tool. Not a discussion about lack of documentation or a feedback thread. All concerns are super valid, but talking about them in the incorrect place are causing me (and I think several others) to miss the importance of all things. So: documentation is another thread, and feedback is another thread. I agree with both of you, but if you put it here it will be lost because they become invisible, cheers, Esteban

On 08 Dec 2014, at 10:55, Torsten Bergmann <astares@gmx.de> wrote:

I would go the opposite direction and rename the "Playground" window to "Workspace".

Several reasons:

1. "Playground" reminds me too much on toyish things (and we had too much of this in the past already, thats why Pharo was forked). The windows intention is to be used for both: prototyping and serious stuff.

2. "Workspace" depicts the area where you usually work and this term is IMHO much much better suited. It is also a common concept known not only in Smalltalk but also other IDE's.

3. I do not understand where the significant shift is (that justifies a new name) as we had similar tools already in the past. Basically it is a script space merged with an inspector, so more an evolution instead of a revolution.

(This does not mean that I'm not happy that the GT tools are now in and provide such an easy to use extensibility!)

3. There is a "Workspace open" but no "Playground open" possibility.

4. Having two separate tools "Workspace" and "Playground" with nearly similar goals (write scripts and inspect objects) would be confusing for newbees.

Maybe we could set up a "community voting" somewhere.

Other things I would like to see: ================================= A. Change to "double clicking" behavior instead of "single clicking" when diving deeper into the iVars of objects.

This would allow to use it as a normal inspector first without having directly more and more panes opening to the right.

Anytime I start with a script in the initial code pane it is moving away when using "Do it and go" and clicking on my objects iVars in the right list view.

With a "double click" the user could decide hisself if he just wants to select (single click to do any other menu item action) or dive deeper into the object (double click).

B. Possibility to have splitters between the opened panes because sometimes the area is not wide enough.

C. When several windows are open the "playgrounds" can not be distinguished by title in the world tool bar.

Note that when I save a workspace contents the title of the workspace window is changed to the *.ws file.

D. Change the initial tab name to something more meaninful (related to C). Or use a better timestamp representation as the current precision. As a human I do not distinguish up to milliseconds when opening such a window. Maybe up to seconds is enough.

Using a tab is questionable by itself - we never have more than one on the initial code pane...

E. Easily saving in the cloud is nice - but I would ask the user before sending it. This prevents wrong usage by accidentially clicking.

Think of usage in a business scenario where you may work with confidential data that would otherwise be posted on the web...

Thanks T.

Hi, This was a long mail :). I tried to address your points below. On Mon, Dec 8, 2014 at 10:55 AM, Torsten Bergmann <astares@gmx.de> wrote:

I would go the opposite direction and rename the "Playground" window to "Workspace".

Several reasons:

1. "Playground" reminds me too much on toyish things (and we had too much of this in the past already, thats why Pharo was forked). The windows intention is to be used for both: prototyping and serious stuff.

Yes, I agree that it is where work can happen. But, it is not the only place where work happens: the debugger or the code is also where work happens :). This is why I find the workspace term misleading. And Playground would match so well the marketing term of "playing with live objects". You might say that Playground is not the only place where people can play with objects, but 2. "Workspace" depicts the area where you usually work and this term is

IMHO much much better suited. It is also a common concept known not only in Smalltalk but also other IDE's.

Not all. Swift calls it Playground (yes, they copied us ;)) 3. I do not understand where the significant shift is (that justifies a

new name) as we had similar tools already in the past. Basically it is a script space merged with an inspector, so more an evolution instead of a revolution.

(This does not mean that I'm not happy that the GT tools are now in and provide such an easy to use extensibility!)

You are looking at it from a technical point of view. Yes, it's just a merge of two features, but it is the end experience that is so much different. That is why I think we have conceptually a different solution than we ever had.

3. There is a "Workspace open" but no "Playground open" possibility.

I think I do not get this point. What do you mean?

4. Having two separate tools "Workspace" and "Playground" with nearly similar goals (write scripts and inspect objects) would be confusing for newbees.

Maybe we could set up a "community voting" somewhere.

Perhaps. Other things I would like to see:

================================= A. Change to "double clicking" behavior instead of "single clicking" when diving deeper into the iVars of objects.

This would allow to use it as a normal inspector first without having directly more and more panes opening to the right.

Anytime I start with a script in the initial code pane it is moving away when using "Do it and go" and clicking on my objects iVars in the right list view.

With a "double click" the user could decide hisself if he just wants to select (single click to do any other menu item action) or dive deeper into the object (double click).

The double click is not a good solution because it would interfere with several use cases. One of them is the ability to go through a list and see the preview to the right. If you would have to double-click or press Enter to get the preview, it would be too hard. I am considering though to allow a pseudo-mode and trigger the selection only when Cmd is pressed, but that is tricky because it can conflict with multiple selections. Another thing we consider is to freeze the first pane. This will likely solve most problems. B. Possibility to have splitters between the opened panes because

sometimes the area is not wide enough.

This is hard to do because having full panes visible at all times (no possibility of seeing half of a pane) is more important. I do not have a solution to marry both of these concerns.

C. When several windows are open the "playgrounds" can not be distinguished by title in the world tool bar.

Note that when I save a workspace contents the title of the workspace window is changed to the *.ws file.

Point taken. This is an area of work that is not finished yet.

D. Change the initial tab name to something more meaninful (related to C). Or use a better timestamp representation as the current precision. As a human I do not distinguish up to milliseconds when opening such a window. Maybe up to seconds is enough.

Using a tab is questionable by itself - we never have more than one on the initial code pane...

This is indeed another area that is not yet quite finished. The time stamp shows the actual name of the file from the play-cache folder. It is not about precision. It is about uniqueness. We could imagine a different scheme that provide a counter, but I do not think this would be any better. We have a "tab" because I would like to get to having multiple playgrounds in the same window. Likely, we should end up being able to change the name of that playground and this will transparently map to a file that will be placed in another dedicated folder (I think of calling it play-stash). At that moment, having the technical label as it is now will be useful to easily distinguish between explicitly labelled and unlabelled playground pages. But, this part clearly needs more work.

E. Easily saving in the cloud is nice - but I would ask the user before sending it. This prevents wrong usage by accidentially clicking.

Think of usage in a business scenario where you may work with confidential data that would otherwise be posted on the web...

Good point! Can you add a bug issue for this? Cheers, Doru

Thanks T.

-- www.tudorgirba.com "Every thing has its own flow"

Hi, On Mon, Dec 8, 2014 at 4:51 PM, Torsten Bergmann <astares@gmx.de> wrote:

...

And Playground would match so well the marketing term of "playing with live objects".

Sorry - but to me it looks like you were catched too much into: now we have to be more modern or rival with all this "lively" stuff (Lighttable IDE, Apple Swift, ...). We all know that being "lively" is something Smalltalk had already years ago and in the best way one can do it.

It's not. Smalltalk model is live, the ui has always been crappy. We have to catch up and stop pretending we are in front because we are not. We can be and we will be, but there is plenty of hard work in front of us.

You might say that Playground is not the only place where people can play with objects, but

Same argument against Workspace is an argument against Playground then. Any reason you did not continue after your "but"?

Sorry. Your mail was too long and I missed this one :). I wanted to say that people can play in the playground, but also play in other places. It is not the same with the usual meaning of work: work is done in the work place / work space.

...

Not all. Swift calls it Playground (yes, they copied us ;))

Because Swift uses this does mean ... (***drumrol***) ... NOTHING. Will we rename BlockClosures to Closures now? Or introduce curly braces? ;)

I did not say that. I simply said that not all environments use the term Workspace.

You are looking at it from a technical point of view. Yes, it's just a merge of two features,

...

but it is the end experience that is so much different.

You said it yourself: we just present it differently. Nothing more. Does a concept really justify a new name if only presented differently?

It's not "just". It's key. It really is :). We have to stop being programmers for a second if we want to produce a proper user experience. Users do not care about what it takes technically. They care about their mental models. This is what has significantly changed.

I really doubt! Otherwise we would have had to rename the concept of a "System Browser" anytime we improved the end user experience (which differs also if you compare old style Squeak browsers and new Nautilus implementation).

Nautilus is a name of a specific system browser, not a concept. It never wanted to be anything else than a System Browser. Btw, the future coding solution will unlikely be called System Browser - :).

That is why I think we have conceptually a different solution than we ever had.

I do not see where it is different now. Diving into object was alway possible with existing tools.

That is not the point. That's a technical detail. The fact that I can get several times faster in creating a visualization or in playing with a query script is what matters.

...

...

3. There is a "Workspace open" but no "Playground open" possibility. I think I do not get this point. What do you mean?

Evaluate

"Workspace open" => it opens a window

"Playground open" => not defined

It is defined: GTPlayground open Still, where does this argument fit?

...

4. Having two separate tools "Workspace" and "Playground" with nearly similar

...

goals (write scripts and inspect objects) would be confusing for

newbees.

...

Maybe we could set up a "community voting" somewhere.

Perhaps.

If we would like to work as a community and respect other opinions it would make sense.

I think this is what the mail was all about, was it not?

So far I guess there are three options discussed:

a) Keep existing "Workspace" tool and add additional "Playground" tool b) One tool with new name "Playground" (no workspace) c) One tool with known name "Workspace" by renaming the Playground tool

Sure. But, this makes some sense only after we have laid out arguments which is what we do right now.

...

Good point! Can you add a bug issue for this?

https://pharo.fogbugz.com/f/cases/14578/Ask-before-saving-in-the-cloud

Thanks!

Doru -- www.tudorgirba.com "Every thing has its own flow"

However, it is precisely those different opinions that are valuable even if it is uncomfortable for the one that proposes a new solution.

Yes, and this is how leaders are judged :-) Alexandre

On Mon, Dec 8, 2014 at 2:18 PM, Alexandre Bergel <alexandre.bergel@me.com <mailto:alexandre.bergel@me.com>> wrote: This is amazing to see such many different opinions. For me, I would keep it innovative and breaking with its legacy. Playground for all! No more workspaces! And yeah, we will have to write new book about that. We are already working on this!

Cheers, Alexandre

...

On Dec 8, 2014, at 3:18 AM, Tudor Girba <tudor@tudorgirba.com <mailto:tudor@tudorgirba.com>> wrote:

Hi,

As you might see, the GTPlayground is called playground not workspace. The main reason for this is that workspace implies the place where work is done, and work is typically associated with creating code.

This is not the intention of the workspace.

Workspace also comes with a history that is associated with actual implementations. While the current GTPlayground might appear to be similar to the workspace, I think the way you can use the latter produces a significant shift.

Furthermore, I think the term playground is more inline with the idea of "playing with live objects". And, in the future, the implementation will likely evolve towards even more liveliness.

It is for this reason that I would prefer that the World menu item gets renamed to Playground.

What do you think?

Cheers, Doru

-- www.tudorgirba.com <http://www.tudorgirba.com/>

"Every thing has its own flow"

-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu <http://www.bergel.eu/> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

-- www.tudorgirba.com <http://www.tudorgirba.com/>

"Every thing has its own flow"

Le 8/12/14 05:43, stepharo a écrit :

Hi doru

I would like to have playground be named playground and that we keep "workspace" but I would like to change the name to "SimpleNoteEditor". Why because this is always good to have simple tools to read from? (I'm not talking about the current workspace implementation but the new one). I would like even try to learn something from Playground implementation because the tools is more advanced while I'm not afraid to learn from a simple tool.

I do not like the idea that we are all forced to use one single tools. We are adults.

Stef

...

Hi,

As you might see, the GTPlayground is called playground not workspace. The main reason for this is that workspace implies the place where work is done, and work is typically associated with creating code.

This is not the intention of the workspace.

Workspace also comes with a history that is associated with actual implementations. While the current GTPlayground might appear to be similar to the workspace, I think the way you can use the latter produces a significant shift.

Furthermore, I think the term playground is more inline with the idea of "playing with live objects". And, in the future, the implementation will likely evolve towards even more liveliness.

It is for this reason that I would prefer that the World menu item gets renamed to Playground.

What do you think?

Cheers, Doru

-- www.tudorgirba.com <http://www.tudorgirba.com>

"Every thing has its own flow"

kilon.alios wrote

I said there is no official documentation, no chapter on PBE or Pharo for the Enterprise.

I see the point. Looking from a new user perspective, how would someone who has not followed the mailing lists for the last few years know that e.g.: - there are two Spec papers, one (which contains some advanced-but-common use cases) which may never have been released (I got it directly from Ben) - various common NB gotchas are only on ML threads (to my knowledge) - the best Zinc documentation is on Sven's site (is there an in-image link)? etc... And now Kilon is projecting that the Playground will have the same difficulty. While premature since 4.0 hasn't been released yet, this seems a valid concern. So how do we provide a single launching point for new users to find relevant documentation? Maybe a start would be to put all these outside links into Help System? To the point of "documentation is hard to write/keep current", the best documentation is executable. And the best executable documentation is part of the development cycle. One area in which IMHO we are severely lacking, and which, if done right, would alleviate some of this stress, is to layer a clear set of BDD-style Behavioral Specifications (Use-case driven acceptance tests) on top of the unit tests. For me, usually our tests were designed from an "is it working" perspective in which "how you use it" is obscured. Bringing it back to the current Workspace -> Playground situation, Specs would be a tremendous help in replacing existing tools because it would be clear what the old tool had promised to users. For me, part of the fear of cleaning up Morphic is always - I don't know what the design contract is! Which parts are internal? Which are experiments? If I implement a new clean TextMorph, what behavior would it have to have? My 2c... ----- Cheers, Sean -- View this message in context: http://forum.world.st/playground-vs-workspace-tp4794667p4794964.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

This is precisely the way we should look at tools: we should identify why we need that tool, but not necessarily stick with the tool.

For example, people said a while ago that the Workspace is better than the Playground for searching for things like implementors. While that might have been the case at that time, I think that use case is better served by the now existing Spotter.

It is important to understand the goal and not focus at the implementation. This is the prerequisite for inventing something new. That is why I keep on asking stupid questions like: "Why do you need this?" "When do you need this?"

Coming back to your point, I think that "note tracker" is one of the last use cases people use a Workspace for. I find this very interesting even if I do not necessarily have this requirement for myself. I think at the moment we can keep a renamed Workspace for that, but in the future we will probably end up with something else. The use case is noted in my book :)

:) And we can always move the txWorkspace into txExamples packages for simple examples :)

Cheers, Doru

On Mon, Dec 8, 2014 at 2:50 PM, stepharo <stepharo@free.fr <mailto:stepharo@free.fr>> wrote:

Le 8/12/14 05:43, stepharo a écrit :

...

Hi doru

I would like to have playground be named playground and that we keep "workspace" but I would like to change the name to "SimpleNoteEditor".

Why because this is always good to have simple tools to read from? (I'm not talking about the current workspace implementation but the new one). I would like even try to learn something from Playground implementation because the tools is more advanced while I'm not afraid to learn from a simple tool.

...

I do not like the idea that we are all forced to use one single tools. We are adults.

Stef

...

Hi,

As you might see, the GTPlayground is called playground not workspace. The main reason for this is that workspace implies the place where work is done, and work is typically associated with creating code.

This is not the intention of the workspace.

Workspace also comes with a history that is associated with actual implementations. While the current GTPlayground might appear to be similar to the workspace, I think the way you can use the latter produces a significant shift.

Furthermore, I think the term playground is more inline with the idea of "playing with live objects". And, in the future, the implementation will likely evolve towards even more liveliness.

It is for this reason that I would prefer that the World menu item gets renamed to Playground.

What do you think?

Cheers, Doru

-- www.tudorgirba.com <http://www.tudorgirba.com>

"Every thing has its own flow"

-- www.tudorgirba.com <http://www.tudorgirba.com>

"Every thing has its own flow"

I wouldn't spend much more time deciding whether to call it playground or workspace, maybe there is a third and better alternative we're not considering. "Playground" evokes me a child space, nonetheless "Light table" isn't a better name. IMO, regardless of the name you choose, with the proper user traction it be accepted. And given how powerful it looks, it certainly will. Regards, El Tue Dec 09 2014 at 10:54:53 AM, Sean P. DeNigris <sean@clipperadams.com> escribió:

stepharo wrote

...

I would like to have playground be named playground and that we keep "workspace" but I would like to change the name to "SimpleNoteEditor".

I like this idea, but think it needs to be developed further. For instance, I would expect syntax highlighting and code completion to be off in a note editor - something like the behavior of the browser's comment pane.

----- Cheers, Sean -- View this message in context: http://forum.world.st/ playground-vs-workspace-tp4794667p4794968.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Doru wrote:

Please look at the mail I sent to Torsten for a more thorough description of my reasoning. For example, I do not like that >it implies that this is *the* place where work happens, and this is clearly not the case.

Think about your arguments. You mentioned that workspace is not the only place where to work. One can work also in the debugger or in the browser. Yes - but a playground is also not the only place where I play with objects. Some people love to play with their objects in the debugger, browser, script manager, or elsewhere...  

Yes, I use the playground extensively for so many use cases. I do not miss the Workspace at all and I do not use it since 2 years.

Maybe because ... (***drumroll***) it is conceptually nothing more than an enhanced workspace. Sorry could'nt resists ;) I stand with my point: the playground is too close to the existing concept of a Workspace to deserve a new name. At the opposite tools like "Spotter" really introduce something conceptually new. Bye T.

Am 08.12.2014 um 20:27 schrieb Tudor Girba <tudor@tudorgirba.com>:

Hi Andreas,

With all due respect for the other Smalltalk (inspired or genuine) environments, I have no intention of waiting for them in order to define the way forward. It’s not about respect for the other Smalltalk environments but for those who work sometimes outside the Pharo world. And you don’t have to wait for anybody. We are talking about the name and not the features. As I said: the changes don’t justify a new name in my eyes. For me what you call GTPlayground is a better workspace than the original one. It will replace the workspace (in Pharo) for me but it is still a workspace.

Our "battle" is with the non-Smalltalk world. This is what we need to convince. And that world does not care about the history of Smalltalk. It cares about how we can solve their problem. That's all.

My experience is that the non-Smalltalk ignorant and GTPlayground, as good as it is, will not convince many people. It’s simply too low-level. Regards Andreas

Cheers, Doru

For me Playground is not even related to what is a Workspace. Therefore these two tools deserve different name in my opinion. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

On Dec 8, 2014, at 4:36 PM, Andreas Wacknitz <a.wacknitz@gmx.de> wrote:

For me what you call GTPlayground is a better workspace than the original one. It will replace the workspace (in Pharo) for me but it is still a workspace.

Hi, We do not yet have an IDE (where I stands for integrated). We have a set of tools and some of them are quite strong. But, we do not have an overall experience yet. Yes, the underlying language model does offer a beautiful experience, but the experience of the tools is far from that. We need tools that are not just powerful in the hands of few specialists, but tools that are beautiful and pleasurable to use in the hands of many. This is the goal. When we will get that, I believe we will change the game. Cheers, Doru On Mon, Dec 8, 2014 at 9:36 PM, kilon alios <kilon.alios@gmail.com> wrote:

"Our "battle" is with the non-Smalltalk world. This is what we need to convince. And that world does not care about the history of Smalltalk. It cares about how we can solve their problem. That's all."

But you already offer an impressive arsenal of tools. The world can complain for several things but what it cannot complain is that Pharo as an IDE is not really powerful as a whole. Your competition would be I assume specialised tools that come as third party. There is no IDE I know out there that offers the level of refactoring of Pharo, in terms of tools and libraries.

Also we should not forget that those tools are not just powerful as is the example of GTPlayground but are engineered in such way to cooperate which each other with ease. While on the other hand , tools for other programming languages are by default separate and independent and not necessarily play nice with each other which the price one pays to keep things modular and unattached to a specific language or IDE. So the way I see it Pharo already is beyond competition.

Unless of course you refer to a comparison tool per tool, which mean you take this pharo tool and you compare with another tool for another language out there. That case would very difficult for you because there are tons of development tools out there.

But the overall idea that is "hey there I give you a language, take this enviroment too, live coding, how about an IDE and also get these coding tools too " is really a dreamy situation already.

The question is how badly coders want a very powerful IDE at least the level of Pharo.

-- www.tudorgirba.com "Every thing has its own flow"

>
> With all due respect for the other Smalltalk (inspired or genuine) 
> environments, I have no intention of waiting for them in order to 
> define the way forward.
+ 10000
> Our "battle" is with the non-Smalltalk world. This is what we need to 
> convince. And that world does not care about the history of Smalltalk. 
> It cares about how we can solve their problem. That's all.
+ 10000

Hi everyone, My intention was to have a discussion based on arguments and to ask for permission to change something I believe in. If I give the impression that I want to name for the sake of naming, I am sorry. And I am sorry I had to disturb so many people with my infatuation. At the same time, I am also quite abated by the fact that too many people look only at what exists and not invest trust in the commitment behind the effort. I will stop responding to this thread now. Thanks for the feedback. Cheers, Doru On Mon, Dec 8, 2014 at 9:30 PM, Hernán Morales Durand < hernan.morales@gmail.com> wrote:

Hello Doru,

I think you have a new different implementation of the classic Workspace, for better or worst.

The problem is everybody wants their tool be named as the highest taxonomic rank. Compare it with naming your cat as "Cat" and not as Siamese Felis Catus which is a specific breed.

On the other side, what prevents for anyone else doing a "better"/new implementation and reclaiming the Workspace name? And this could happen every year? I don't know you but I get bored of seeing "I want that name" discussions.

Workspace is a type of tool, it happens that there is an implementation which owned such name. It should be renamed as OldWorkspace, DeveloperWorkspace, ClassicWorkspace, or whatever.

For me, Workspace in the World menu should display a sub-menu with both implementations. And community gains a place to display/register more implementations discriminated by its type.

Hernán

2014-12-08 3:18 GMT-03:00 Tudor Girba <tudor@tudorgirba.com>:

Hi,

...

As you might see, the GTPlayground is called playground not workspace. The main reason for this is that workspace implies the place where work is done, and work is typically associated with creating code.

This is not the intention of the workspace.

Workspace also comes with a history that is associated with actual implementations. While the current GTPlayground might appear to be similar to the workspace, I think the way you can use the latter produces a significant shift.

Furthermore, I think the term playground is more inline with the idea of "playing with live objects". And, in the future, the implementation will likely evolve towards even more liveliness.

It is for this reason that I would prefer that the World menu item gets renamed to Playground.

What do you think?

Cheers, Doru

-- www.tudorgirba.com

"Every thing has its own flow"

-- www.tudorgirba.com "Every thing has its own flow"

2014-12-09 11:06 GMT+01:00 Sven Van Caekenberghe <sven@stfx.eu>:

...

On 08 Dec 2014, at 22:53, Tudor Girba <tudor@tudorgirba.com> wrote:

Hi everyone,

My intention was to have a discussion based on arguments and to ask for permission to change something I believe in. If I give the impression that I want to name for the sake of naming, I am sorry. And I am sorry I had to disturb so many people with my infatuation.

At the same time, I am also quite abated by the fact that too many people look only at what exists and not invest trust in the commitment behind the effort.

I will stop responding to this thread now.

OK, fair enough, but please don't stop what you are doing ;-)

+1000 IMO, I do not care of the name. Playground is good enough to me and Alex is right, next doc will be up to date. GTTools are innovatives and we must push them for a better and nicer Pharo. Obviously, we should also take care of not loosing good stuff from the existing tools and it is not the case here between Workspace and Playground. So thx Doru, and please keep pushing ;-) Luc

...

Thanks for the feedback.

Cheers, Doru

On Mon, Dec 8, 2014 at 9:30 PM, Hernán Morales Durand < hernan.morales@gmail.com> wrote: Hello Doru,

I think you have a new different implementation of the classic Workspace, for better or worst.

The problem is everybody wants their tool be named as the highest taxonomic rank. Compare it with naming your cat as "Cat" and not as Siamese Felis Catus which is a specific breed.

On the other side, what prevents for anyone else doing a "better"/new implementation and reclaiming the Workspace name? And this could happen every year? I don't know you but I get bored of seeing "I want that name" discussions.

Workspace is a type of tool, it happens that there is an implementation which owned such name. It should be renamed as OldWorkspace, DeveloperWorkspace, ClassicWorkspace, or whatever.

For me, Workspace in the World menu should display a sub-menu with both implementations. And community gains a place to display/register more implementations discriminated by its type.

Hernán

2014-12-08 3:18 GMT-03:00 Tudor Girba <tudor@tudorgirba.com>:

Hi,

As you might see, the GTPlayground is called playground not workspace. The main reason for this is that workspace implies the place where work is done, and work is typically associated with creating code.

This is not the intention of the workspace.

Workspace also comes with a history that is associated with actual implementations. While the current GTPlayground might appear to be similar to the workspace, I think the way you can use the latter produces a significant shift.

Furthermore, I think the term playground is more inline with the idea of "playing with live objects". And, in the future, the implementation will likely evolve towards even more liveliness.

It is for this reason that I would prefer that the World menu item gets renamed to Playground.

What do you think?

Cheers, Doru

-- www.tudorgirba.com

"Every thing has its own flow"

-- www.tudorgirba.com

"Every thing has its own flow"