[Pharo-users] Pharo + git workflow

Dimitris Chloupis kilon.alios at gmail.com
Tue Jan 26 13:10:59 EST 2016


I love live coding , dynamic language, beautiful syntax and close
integration with IDE. But yeah Monticello , I don't get it. I love Pharo
and always respect the hard work of others but that does not mean I love
every part of it. Same story is Blender , Python and all other tools I use.
That ok I don't worry if some parts I don't like. It's what make with the
tools you have that matters most.
On Tue, 26 Jan 2016 at 19:46, Sven Van Caekenberghe <sven at stfx.eu> wrote:

> Sometimes I really don't understand what you see in Pharo ...
>
> > On 26 Jan 2016, at 17:53, Dimitris Chloupis <kilon.alios at gmail.com>
> wrote:
> >
> > "If git compares two versions, it does not understand what is in it."
> >
> > why it should ? its a version control system, not a refactoring tool.
> >
> > "
> > When Monticello compares versions, it knows about classes, methods,
> inheritance,
> > it can explain diffs in the same structured (browsable) form that you
> wrote them."
> >
> > is that Monticello or is that refactoring classes and methods of pharo ?
> Because the way I see it is like this if you have a refactoring language, a
> language that can refactor its own code , that language should be able to
> take two diffirent pieces of code and not only show you a diff but also
> show you how your inheritance is affected, your classes even your live
> state.
> >
> > The big question here, from my side is why a version control system
> should do that ? Refactoring and version controlling for me at least is two
> very different tasks. I dont also see how a version control system that is
> self aware refactoring wise when  already have refactoring tools in my IDE,
> is giving me any advantage me as a user. Most IDEs come with them anyway.
> >
> > Its not as if you will use a python IDE, or whatever language you use
> and the IDE will go "sorry dude I cannot tell you what git did there
> because it has no refactoring and I am too stupid to use my own refactoring
> tools". That IDE would belong to the bin. This is why we use specialized
> Git gui tools, they are not there just to make our screens pretty.
> >
> > "Putting Smalltalk in plain text files can be done, has been done, and
> was not successful, because you lose something essential by leaving the
> environment."
> >
> > What you lose is the live state which monticello does not store anyway,
> how could it ? it only stores text files, its actually far more
> anti-Smalltalk than git is. Because with git you can version control your
> pharo images or your fuel files than contain the live state or you could
> export the live state and live code to a binary file. Now try that with
> monticello.  The irony is very large, Git is far more Smalltalk friendly,
> than Monticello is.
> >
> > "The island argument is also a bit too easy: any platform can be seen as
> an island that needs to integrate with others, there are degrees of
> openness. Your Blender or Python are islands too, just like SAP, Microsoft
> and Oracle. Some connections/interfaces are easy, some are hard(er). It all
> depends on your position."
> >
> > I completely agree in the end every API ever programm is to a degree an
> island. No code ever shakes in terror saying "oh my god I need to make my
> code 100% compatible with whatever is out there" . Its not possible. But
> the culture of those other languages is "lets keep things close" , "lets
> make coder's life" easier , "lets keep compatibility and standard/common
> practices" .
> >
> > Smalltalk does not do that because it loves experimentation, the whole
> smalltalk enviroment  is experimentation heaven playground. Thats great
> because without it we dont have smalltalk but its also bad.
> >
> > "When have you last looked at the source code of git ?"
> >
> > Never ? Why should I, I dont even take a look at monticello source code.
> I tried to improve auto completion and my head kept spinning around and
> around, 10s of hours still could not figure out the code. I am not smart or
> knowledgable to judge Monticello on a source code basis. Maybe source code
> wise, core wise, Monticello is 1000 times better than Git, but my complains
> with Monticello is on the user level. As a smalltalker I just dont see the
> point of prefering Monticello over Git , or screw Git, you want mercurial ?
> thats fine too.
> >
> > I just dont see it whats the big deal with Monticello.
> >
> > "And be honest, do you find git always easy to use ?"
> >
> > I have been honest from the very start when I started pushing for git
> and Github. I have been crystal clear. My usage of git is super simple.
> >
> > I dont work in teams, I work alone, I dont even use branches, I do git
> pull, git add, git commit and git push. I have reverted commits a couple of
> times, I have reset to head sometimes because of some nasty merges and that
> was it.  I am almost never have merge conflicts.
> >
> > You want me to compare my experience with monticello and StHub VS git
> and Github using Pharo ? Nope you dont.
> >
> > Do I find git always easy to use ? You know what , I am a python coder
> and I definetly appreciate ease of use and simplicity but lets be frank
> here Git was made by the same guy that made the freaking Linux kernel. He
> made Git not to be easy but able to manage an enormous amount of code the
> easy way the fastest possible way and he accomplished that goal.
> >
> > So do I find git easy to use ? Nope
> >
> > Do I care ? Nope, because I rather use something that is difficult to
> use but powerful and with good performance than something that is very easy
> to use , limited and slow. Hell , I dont even find Pharo easy to use , its
> power and flexibility that made me love it.
> >
> >
> > On Tue, Jan 26, 2016 at 6:23 PM Sven Van Caekenberghe <sven at stfx.eu>
> wrote:
> >
> > > On 26 Jan 2016, at 16:49, Dimitris Chloupis <kilon.alios at gmail.com>
> wrote:
> > >
> > > Obviously it will better fit Pharo since its made to work with
> smalltalk code, but that does not make it any less terrible. Just because
> you have one implementation of something that does not mean its good. Its
> just means its there and it works.
> > >
> > > I dont know the internal, they are not documented anyway, there are
> some class comments here and there but thats pretty much it. I dont even
> remember when was the last time monticello got an updated, I mean a serious
> update not just a couple of bug fixes the 2 years I have been around.
> > >
> > > Secondly GUI is just plain awful, Smalltalk maybe be the first or one
> of the first to implement guis, but those implementations never ended up to
> something that would be approachable and easy to use on a day to day basis,
> some tools suffer more from this some less, Monticello is up there with the
> worse design.
> > >
> > > Thirdly the inability of the system to version control images , audio
> files and other assets it defeats the central purpose of smalltalk of
> everything being objects with a loud "Nope !" from Monticello "Only source
> code is".
> > >
> > > So its awesome that Smalltalk , and Squeak got its own version control
> system, that is easy to use and Pharo inherited it. Congratulations to
> people behind it. But the GUI needs to go, its a bad advertisement to
> Pharo, and we need something that is not stuck to dark ages as you
> correctly pointed but for the opposite reason. Because any way you try to
> turn Monticello you wont find a label written "modern" on it. The label you
> may find on it is more like "abandonware".
> > >
> > > Also there like a ton of OOP languages out there using git with no
> major problems, the problem with smalltalk is that smalltalk is an island.
> > >
> > > And the problem with islands is when you end having fun with them you
> feel stuck since they dont provide an easy access to the outside world.
> > >
> > > "Git just manages blobs, text files at best. Dead text"
> > >
> > > Last time I checked Monticello used a format called mcz which is
> nothing more than a zip file containing st files, which are as you call it
> "dead text" files. Also I would like to remind you that git is used by the
> CUIS smalltalk to version control their images, I thought images are live
> code.
> > >
> > > Personally I dont see the diffirence between live and dead text. Its
> just text to me. The VM is the one that makes it live anyway.
> >
> > Yes and no.
> >
> > If git compares two versions, it does not understand what is in it.
> >
> > When Monticello compares versions, it knows about classes, methods,
> inheritance,
> > it can explain diffs in the same structured (browsable) form that you
> wrote them.
> >
> > Putting Smalltalk in plain text files can be done, has been done, and
> was not successful, because you lose something essential by leaving the
> environment.
> >
> > The island argument is also a bit too easy: any platform can be seen as
> an island that needs to integrate with others, there are degrees of
> openness. Your Blender or Python are islands too, just like SAP, Microsoft
> and Oracle. Some connections/interfaces are easy, some are hard(er). It all
> depends on your position.
> >
> > When have you last looked at the source code of git ?
> >
> > And be honest, do you find git always easy to use ?
> >
> > > On Tue, Jan 26, 2016 at 5:09 PM Sven Van Caekenberghe <sven at stfx.eu>
> wrote:
> > >
> > > > On 26 Jan 2016, at 15:59, Dimitris Chloupis <kilon.alios at gmail.com>
> wrote:
> > > >
> > > > To be fair my experience with pharo and git have been not always
> smooth either. I have the VM crashing again and again completely randomly
> when it was trying to pull SmaCC as dependency for my project Ephestos, had
> to drop SmaCC and moving my python type parsing at python side.
> > > >
> > > > But I find it ironic someone using Monticello, trying to equate git
> with dark ages, you cant get more dark ages than monticello, frankly. No
> offense to people who made it , its great that is in there but its full of
> problems and bad designs and cant even begin to be compared with Github and
> GIT GUI clients. Monticello is according to my personal opinion by far the
> worst tool of Pharo.
> > >
> > > No it is not. It is a version management system that understands our
> object and code model, a system that we control. Git just manages blobs,
> text files at best. Dead text.
> > >
> > > (This does not mean it is perfect, nor that it cannot improve, nor
> that we should not improve our git integration.)
> > >
> > > > On Tue, Jan 26, 2016 at 4:51 PM Thierry Goubier <
> thierry.goubier at gmail.com> wrote:
> > > > 2016-01-26 15:11 GMT+01:00 Sean P. DeNigris <sean at clipperadams.com>:
> > > > NorbertHartl wrote
> > > > > - I need to use BaselineOf instead of ConfigurationOf. Thus you
> cannot use
> > > > > Versionner anymore
> > > >
> > > > Unfortunately. This is the biggest drag for me after switching all my
> > > > personal projects to git (GitHub for public and BitBucket for
> private). I
> > > > had gotten spoiled by Versionner and hand-editing MetaC artifacts
> feels like
> > > > going back to the dark ages :/
> > > >
> > > > Well, I guess copying the baselines generated by Versionner into a
> BaselineOf is probably a way to do it.
> > > >
> > > > Thierry
> > > >
> > > >
> > > >
> > > >
> > > > -----
> > > > Cheers,
> > > > Sean
> > > > --
> > > > View this message in context:
> http://forum.world.st/Pharo-git-workflow-tp4874067p4874221.html
> > > > Sent from the Pharo Smalltalk Users mailing list archive at
> Nabble.com.
> > > >
> > >
> > >
> >
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-users_lists.pharo.org/attachments/20160126/6de3e9c6/attachment.html>


More information about the Pharo-users mailing list