Sometimes I really don't understand what you see in Pharo ...
> On 26 Jan 2016, at 17:53, Dimitris Chloupis <kilon.al...@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 <s...@stfx.eu> wrote:
>
> > On 26 Jan 2016, at 16:49, Dimitris Chloupis <kilon.al...@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 <s...@stfx.eu> wrote:
> >
> > > On 26 Jan 2016, at 15:59, Dimitris Chloupis <kilon.al...@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.goub...@gmail.com> wrote:
> > > 2016-01-26 15:11 GMT+01:00 Sean P. DeNigris <s...@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.
> > >
> >
> >
>
>
