Nautilus as default/only Systembrowser for pharo3
Hi, is Nautilus supposed to be the default or only Systembrowser for the next Pharo release? Nicolai
On 16 Dec 2013, at 12:53, Nicolai Hess <nicolaihess@web.de> wrote:
Hi,
is Nautilus supposed to be the default or only Systembrowser for the next Pharo release?
Default. The release will just be what you download now plus fixes that people do from now till March. The old Browser will still be in there as we do not have the manpower to remove it (there is a subclass that needs to be re-implemented), but it starts to degenerate as it is not used⦠as it always happens. (and we do not want to put manpower there, it is better spend on Nautilus) Marcus
2013/12/16 Marcus Denker <marcus.denker@inria.fr>
On 16 Dec 2013, at 12:53, Nicolai Hess <nicolaihess@web.de> wrote:
Hi,
is Nautilus supposed to be the default or only Systembrowser for the next Pharo release?
Default. The release will just be what you download now plus fixes that people do from now till March.
The old Browser will still be in there as we do not have the manpower to remove it (there is a subclass that needs to be re-implemented), but it starts to degenerate as it is not used⦠as it always happens. (and we do not want to put manpower there, it is better spend on Nautilus)
Marcus
I really like Nautilus, the groups, the history navigation, the code panel with the color warning for long methods. It is good doing experiments with new or better developer tools. But some parts just looking as "quickly hacked into it", just to make it running. And there are bugs. Nautilus could need some refactoring/code cleanup. In my point of view, in a clean and stable pharo release, all smalltalks tools (browser debugger inspectro ...) should show you "look, thats the way of doing it in smalltalk /pharo". I would really like to more emphasis on "clean and stable". nicolai
We are always open to cool slices :P Ben On 16 Dec 2013, at 16:26, Nicolai Hess <nicolaihess@web.de> wrote:
2013/12/16 Marcus Denker <marcus.denker@inria.fr>
On 16 Dec 2013, at 12:53, Nicolai Hess <nicolaihess@web.de> wrote:
Hi,
is Nautilus supposed to be the default or only Systembrowser for the next Pharo release?
Default. The release will just be what you download now plus fixes that people do from now till March.
The old Browser will still be in there as we do not have the manpower to remove it (there is a subclass that needs to be re-implemented), but it starts to degenerate as it is not used⦠as it always happens. (and we do not want to put manpower there, it is better spend on Nautilus)
Marcus
I really like Nautilus, the groups, the history navigation, the code panel with the color warning for long methods. It is good doing experiments with new or better developer tools.
But some parts just looking as "quickly hacked into it", just to make it running. And there are bugs. Nautilus could need some refactoring/code cleanup.
In my point of view, in a clean and stable pharo release, all smalltalks tools (browser debugger inspectro ...) should show you "look, thats the way of doing it in smalltalk /pharo".
I would really like to more emphasis on "clean and stable".
nicolai
On 16 Dec 2013, at 16:26, Nicolai Hess <nicolaihess@web.de> wrote:
I really like Nautilus, the groups, the history navigation, the code panel with the color warning for long methods. It is good doing experiments with new or better developer tools.
But some parts just looking as "quickly hacked into it", just to make it running. And there are bugs. Nautilus could need some refactoring/code cleanup.
In my point of view, in a clean and stable pharo release, all smalltalks tools (browser debugger inspectro ...) should show you "look, thats the way of doing it in smalltalk /pharo".
I would really like to more emphasis on "clean and stableâ.
Yes.. the problem is not the âwantâ but the âdoâ⦠in the end we always need to manage it with the limited resources we have⦠Marcus
I really like Nautilus, the groups, the history navigation, the code panel with the color warning for long methods. It is good doing experiments with new or better developer tools.
But some parts just looking as "quickly hacked into it", just to make it running. And there are bugs. Nautilus could need some refactoring/code cleanup.
In my point of view, in a clean and stable pharo release, all smalltalks tools (browser debugger inspectro ...) should show you "look, thats the way of doing it in smalltalk /pharo".
I would really like to more emphasis on "clean and stableâ.
Oh yes. Now if somebody has 5 engineers that do not know what to do, I have some ideas :)
Yes.. the problem is not the âwantâ but the âdoâ⦠in the end we always need to manage it with the limited resources we haveâ¦
+ 1 This is why we should simplify and clean it. Stef
I agree too , having realistic expectations is the wise thing to do. All of us want the Stars and the Moon , the question is what we can really have and that we all or at least most of us do contribute even in very small portions. Whats better way to live than improve the very things we love ? Personally I love all the new "unclean" things I see in pharo. Why keep things in a closet because of unknown bugs, unleash them to the world and let the world shape them to something mature. Thats how you make great code. On Tue, Dec 24, 2013 at 3:52 PM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
I really like Nautilus, the groups, the history navigation, the code panel with the color warning for long methods. It is good doing experiments with new or better developer tools.
But some parts just looking as "quickly hacked into it", just to make it running. And there are bugs. Nautilus could need some refactoring/code cleanup.
In my point of view, in a clean and stable pharo release, all smalltalks tools (browser debugger inspectro ...) should show you "look, thats the way of doing it in smalltalk /pharo".
I would really like to more emphasis on "clean and stableâ.
Oh yes. Now if somebody has 5 engineers that do not know what to do, I have some ideas :)
Yes.. the problem is not the âwantâ but the âdoâ⦠in the end we always need to manage it with the limited resources we haveâ¦
+ 1 This is why we should simplify and clean it.
Stef
2013/12/24 kilon alios <kilon.alios@gmail.com>
I agree too , having realistic expectations is the wise thing to do. All of us want the Stars and the Moon , the question is what we can really have and that we all or at least most of us do contribute even in very small portions. Whats better way to live than improve the very things we love ?
Personally I love all the new "unclean" things I see in pharo. Why keep things in a closet because of unknown bugs, unleash them to the world and let the world shape them to something mature. Thats how you make great code.
On Tue, Dec 24, 2013 at 3:52 PM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:
I really like Nautilus, the groups, the history navigation, the code panel with the color warning for long methods. It is good doing experiments with new or better developer tools.
But some parts just looking as "quickly hacked into it", just to make it running. And there are bugs. Nautilus could need some refactoring/code cleanup.
In my point of view, in a clean and stable pharo release, all smalltalks tools (browser debugger inspectro ...) should show you "look, thats the way of doing it in smalltalk /pharo".
I would really like to more emphasis on "clean and stableâ.
Oh yes. Now if somebody has 5 engineers that do not know what to do, I have some ideas :)
Yes.. the problem is not the âwantâ but the âdoâ⦠in the end we always need to manage it with the limited resources we haveâ¦
+ 1 This is why we should simplify and clean it.
Stef
I understand, lack of time/manpower. But if we have the time, to introduce new or experimental things, we should focus to have stable tools.
there is no "should" in a open source project. Saying that I very much doubt it there is a single pharoer that does not care about the stability and improvement of his own code. Experimentation is part of the game of learning, and without learning you can have no bug fixes. If you don't understand the problem then you cant fix it. Or even worse you may think its not broken in the first place. On Tue, Dec 24, 2013 at 11:06 PM, Nicolai Hess <nicolaihess@web.de> wrote:
2013/12/24 kilon alios <kilon.alios@gmail.com>
I agree too , having realistic expectations is the wise thing to do. All of us want the Stars and the Moon , the question is what we can really have and that we all or at least most of us do contribute even in very small portions. Whats better way to live than improve the very things we love ?
Personally I love all the new "unclean" things I see in pharo. Why keep things in a closet because of unknown bugs, unleash them to the world and let the world shape them to something mature. Thats how you make great code.
On Tue, Dec 24, 2013 at 3:52 PM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:
I really like Nautilus, the groups, the history navigation, the code panel with the color warning for long methods. It is good doing experiments with new or better developer tools.
But some parts just looking as "quickly hacked into it", just to make it running. And there are bugs. Nautilus could need some refactoring/code cleanup.
In my point of view, in a clean and stable pharo release, all smalltalks tools (browser debugger inspectro ...) should show you "look, thats the way of doing it in smalltalk /pharo".
I would really like to more emphasis on "clean and stableâ.
Oh yes. Now if somebody has 5 engineers that do not know what to do, I have some ideas :)
Yes.. the problem is not the âwantâ but the âdoâ⦠in the end we always need to manage it with the limited resources we haveâ¦
+ 1 This is why we should simplify and clean it.
Stef
I understand, lack of time/manpower. But if we have the time, to introduce new or experimental things, we should focus to have stable tools.
I understand, lack of time/manpower. But if we have the time, to introduce new or experimental things, we should focus to have stable tools.
Believe me that I completely agree with you :). Iâm always trying to get stable and better tools. What are the problems that you have? Because I work daily with Nautilus. Now you should realise that Ben did Nautilus because he was fed up with the old browser and he was a third and four year student. Then he built nautilus so that we can remove the really old code StringHolder and subclasses from the system. Then from this experience we saw that building tools did not scale so this is why we worked on Spec. And now Spec went from version 1 to version 2 and now we will be able to rewrite Nautilus again. Now to complete the story: we worked one year to clean and make a solid version of package but protocols were so deep into the system that we had to fix Nautilus and esteban rewrote a part in a hurry. But again Esteban is not payed for that and some of the glitches we will be fixed when we find them and fix them. Stef
participants (5)
-
Benjamin -
kilon alios -
Marcus Denker -
Nicolai Hess -
Stéphane Ducasse