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
<mailto: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 <mailto: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 <mailto:s...@stfx.eu>> wrote:
>
> > On 26 Jan 2016, at 16:49, Dimitris Chloupis
<kilon.al...@gmail.com <mailto: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 <mailto:s...@stfx.eu>> wrote:
> >
> > > On 26 Jan 2016, at 15:59, Dimitris Chloupis
<kilon.al...@gmail.com <mailto: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 <mailto:thierry.goub...@gmail.com>> wrote:
> > > 2016-01-26 15:11 GMT+01:00 Sean P. DeNigris
<s...@clipperadams.com <mailto: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.
> > >
> >
> >
>
>
