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 <s...@stfx.eu> wrote:
> 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. > > > > > > > > > > > > > > > > >
