Kilon wrote:
I just don't see it the way you do.
That's fine, you work in a different context than we do. What do you disagree on? You might have missed a discussion on the Moose list. There Stef proposed to use Versioner to manage the Moose configuration, and use it in a specific way. We noticed some problems, and try to explain where they come from in order to get an improved situation.
For me Versioner is a tool to make life a bit easier with Configurations, its not "the one ring to rule them all" , far from it.
Versioner makes life easier for a specific kind of projects. It is important to be aware of its limitations.
What stops anyone from implementing his own configuration tool ?
Common sense, I hope... Stephan
On Mon, Jun 30, 2014 at 8:49 AM, Stephan Eggermont <stephan@stack.nl> wrote:
Kilon wrote:
I just don't see it the way you do. Versioner makes life easier for a specific kind of projects. It is important to be aware of its limitations.
What stops anyone from implementing his own configuration tool ?
Common sense, I hope...
Kilon has a point and so does Stephan ... In a programming language where the development environment allows script-based tools (as opposed to GUI-based tools) it is much easier to construct custom "tools" to support variations in workflow ... individual developers routinely copy/share scripts that routinely need to be customized for their environment ... Smalltalk with it's heavy reliance on GUI-based tools is not quite as easy to customize (for several reasons) ... before knickers get knotted, please keep in mind that I think that customizable GUI-based tools are important, it's just that the GUI raises the entry level bar a bit higher than it needs to be... There is room in Smalltalk for plain old-fashioned scripts (workspaces don't quite cut it in this regard) that can be easily shared and customized (and written in Smalltalk) ... anway, some (breakfast) food for thought... Dale
2014-06-30 13:15 GMT-03:00 Dale Henrichs <dale.henrichs@gemtalksystems.com>:
Smalltalk with it's heavy reliance on GUI-based tools is not quite as easy to customize (for several reasons) ... before knickers get knotted, please keep in mind that I think that customizable GUI-based tools are important, it's just that the GUI raises the entry level bar a bit higher than it needs to be...
There is room in Smalltalk for plain old-fashioned scripts (workspaces don't quite cut it in this regard) that can be easily shared and customized (and written in Smalltalk) ...
anway, some (breakfast) food for thought...
This is, in my opinion, a flaw that affects any system born as a GUI. There was no CLI culture in the past. It happens to Smalltalk, obviously, and also affected Microsoft (another UI centric OS) who had to put a lot of effort (and $$$) to add command line support for most of their solutions, as a response to devops and similar users. Mac got developer traction since they put BSD underneath a fancy GUI. According to the Unix Philosophy (http://en.wikipedia.org/wiki/Unix_philosophy) Smalltalk, and Pharo, are compliant with the "Rule of Modularity" whitin the image, but not with the "Rule of composition" as seen from external programs. Pharo's command line support is certainly better than before. But we're not there yet, when even web pages are mostly composed/scaffolded/provisioned using CLI tools today instead of using behemont tools like Dreamweaver/Expression. This is also food for thought. In case anybody is still hungry. :) Regards!
Esteban, Just to be clear, I believe that there should be Smalltalk scripting/cli from within the image (augment workspace usage) as well as from without ... more food (for lunch) thought:) Dale On Mon, Jun 30, 2014 at 11:36 AM, Esteban A. Maringolo <emaringolo@gmail.com
wrote:
2014-06-30 13:15 GMT-03:00 Dale Henrichs <dale.henrichs@gemtalksystems.com
: Smalltalk with it's heavy reliance on GUI-based tools is not quite as easy to customize (for several reasons) ... before knickers get knotted, please keep in mind that I think that customizable GUI-based tools are important, it's just that the GUI raises the entry level bar a bit higher than it needs to be...
There is room in Smalltalk for plain old-fashioned scripts (workspaces don't quite cut it in this regard) that can be easily shared and customized (and written in Smalltalk) ...
anway, some (breakfast) food for thought...
This is, in my opinion, a flaw that affects any system born as a GUI. There was no CLI culture in the past. It happens to Smalltalk, obviously, and also affected Microsoft (another UI centric OS) who had to put a lot of effort (and $$$) to add command line support for most of their solutions, as a response to devops and similar users. Mac got developer traction since they put BSD underneath a fancy GUI.
According to the Unix Philosophy ( http://en.wikipedia.org/wiki/Unix_philosophy)
Smalltalk, and Pharo, are compliant with the "Rule of Modularity" whitin the image, but not with the "Rule of composition" as seen from external programs.
Pharo's command line support is certainly better than before. But we're not there yet, when even web pages are mostly composed/scaffolded/provisioned using CLI tools today instead of using behemont tools like Dreamweaver/Expression.
This is also food for thought. In case anybody is still hungry. :)
Regards!
----------------Stephan--------------- "That's fine, you work in a different context than we do. What do you disagree on?" I disagreed with this Stephan "That being said, I am getting a bit nervous about how versioner is released. It should aim to improve the way people can work, and *not* to create a single workflow for all people working on pharo projects. I hope my fears are unfounded." this what I was replying to. "You might have missed a discussion on the Moose list. There Stef proposed to use Versioner to manage the Moose configuration, and use it in a specific way. We noticed some problems, and try to explain where they come from in order to get an improved situation." I have read through it yes, I did not argue that Versioner is perfect. I am actually arguing the opposite, that is a rather basic tool, it gets some basic tasks done but obviously its not the "one ring to rule them all" meaning its up to pharo developers to contribute and improve it or create additional tools to assist with tasks that Versioner can't handle. I disagree that it has an agenda to enforce a single workflow. It is what it is and it can be improved. "Common sense, I hope..." So basically what you saying is that being in a environment ( Pharo ) which is making it easier to create your own IDE tools is not common sense to create your own IDE tools ? You want to join efforts that fine , you want to do it your own way thats fine too, the end result is tools that solve problems. Obviously joining effort is the preferable choice, but doing your own thing is a recipe that Pharo has been based on. I think its great to have these discussion so people are aware of problems before they face them in real life. I definitely would love to read about these problems and plan ahead my actions. If its a problem for Moose people there is no reason to believe it won't be a problem for others in the near future. ----------Dale------------- "Smalltalk with it's heavy reliance on GUI-based tools is not quite as easy to customize (for several reasons) ... before knickers get knotted, please keep in mind that I think that customizable GUI-based tools are important, it's just that the GUI raises the entry level bar a bit higher than it needs to be... " I can't speak for others but I would say that for me is lack of documentation mainly, I am actually learning Rubric slowly, obviously I don't code in Pharo full time as some of you nor I have years of experience in my back, reading and understanding code is a slow process. If those tools were well documented there would be a lot more people hacking them and contributing to them since it would lower the steep learning curve quite substantially. But I can understand that Pharo has not the amount of people that for example emacs has to provide an in depth documentation about its tools and libraries and I try to help it to come one step closer. I don't think not having GUIs is a problem for me. I did not have issues working with Metacello . I actually recently started using Versioner and I use it for the simple stuff, have no issues falling back to metacello if I have to. Pharo puts emphasis on GUI but it should not be viewed as a mandatory requirement. I am actually working on making Workspace behave similar to emacs with as less GUI as possible. There is even a tool to run a shell terminal inside Pharo and of course we should forget that Pharo runs from terminal too.
On Mon, Jun 30, 2014 at 10:01 AM, kilon alios <kilon.alios@gmail.com> wrote:
----------Dale-------------
"Smalltalk with it's heavy reliance on GUI-based tools is not quite as easy to customize (for several reasons) ... before knickers get knotted, please keep in mind that I think that customizable GUI-based tools are important, it's just that the GUI raises the entry level bar a bit higher than it needs to be... "
I can't speak for others but I would say that for me is lack of documentation mainly, I am actually learning Rubric slowly, obviously I don't code in Pharo full time as some of you nor I have years of experience in my back, reading and understanding code is a slow process. If those tools were well documented there would be a lot more people hacking them and contributing to them since it would lower the steep learning curve quite substantially. But I can understand that Pharo has not the amount of people that for example emacs has to provide an in depth documentation about its tools and libraries and I try to help it to come one step closer.
I don't think not having GUIs is a problem for me. I did not have issues working with Metacello . I actually recently started using Versioner and I use it for the simple stuff, have no issues falling back to metacello if I have to. Pharo puts emphasis on GUI but it should not be viewed as a mandatory requirement. I am actually working on making Workspace behave similar to emacs with as less GUI as possible. There is even a tool to run a shell terminal inside Pharo and of course we should forget that Pharo runs from terminal too.
Cool! I really think it is worthwhile exploring the territory "below the GUI" or "with minimal GUI" ... there is no question that a good GUI tool is very useful, but there is a place for the stripped down minimal effort tools as well ... Dale
participants (4)
-
Dale Henrichs -
Esteban A. Maringolo -
kilon alios -
Stephan Eggermont