Hi Dimitris,
i as a simple user tend to think about these things in simple terms: i
download a program, add something, upload my addition. lets take an
upload step, _one_ simple step with monticello: i upload something once
(git add), i upload it a second time (git commit), i upload it a third
time (git push), i try to upload it a fourth time (pull request), only
then i'm done (yes, there are possible shortcuts but so what). i'm sure
all this makes sense for the seasoned coder, but i certainly won't learn
that. <friendly grin> just as a small example how a user like me thinks
about this.
werner
On 01/14/2017 03:14 PM, Dimitris Chloupis wrote:
On Sat, Jan 14, 2017 at 3:21 PM Sven Van Caekenberghe <s...@stfx.eu
<mailto:s...@stfx.eu>> wrote:
> On 14 Jan 2017, at 12:58, Dimitris Chloupis
<kilon.al...@gmail.com <mailto:kilon.al...@gmail.com>> wrote:
>
> I fail to see what is user friendly about Monticello , I find
its GUI and the total workflow really bad, certainly the worst VCS
GUI I have ever used. But I will admit this is my personal taste
and my opinion that can be safely ignore.
That is your opinion and you are entitled to it, but I am pretty
sure you don't speak for the majority of Smalltalk users in general.
The only way to know for sure is to do some form of survey, but as I
said its my opinion. Even if others agree with me, we still may have
different opinions.
I don't understand what is bad about MC in the IDE: your code is
easily put in packages, you look at changes at the method and
class definition level, you compare and commit, look at incoming
changes and that's it. Merging is just as easy or difficult as
anywhere else.
My reason for not liking Monticello
a) GUI looks ugly
b) GUI opens needless windows (a generic Pharo problem)
c) No syntax highlighting in case of Browsing online code (diffs,
changes etc)
d) No visualization of the commit history.
e) the usual problems with documentation
f) No easy undo functionality
g) Need to press a refresh button for monticello to be kept up to date
h) Monticello contacts irrelevant online repos even for local commits,
as a result a slow connection can freeze the image (WTF)
i) No clear indication of where the history branches and where it merges
and the list goes on , but those are the main
I wonder even if Monticello improved at all since Pharo forked from
Squeak.
It is true that StHub is not actively maintained, but that does
not change the fact that it just works. Indeed certain features
were/are missing, nothing is perfect. Given the load is has to
endure it is pretty stable (remember that SqueakSource collapsed
under the Pharo load) even if it needs an occasional reset.
"nothing is perfect" is a lousy excuse and a cliche. Yes it works but
this is not the image I think that will inspire newcomers to use Pharo.
Remember we have to compete with languages like Ruby and Python .
Here is an example. I have this pull request open
https://github.com/svenvc/ston/pull/17/files
it is so big, changes so much that I cannot even begin figuring
out what happened. I want my in-IDE tools that understand Smalltalk.
One sec... one sec
are you trying to tell me that this a good commit ?
https://github.com/svenvc/ston/pull/17/commits/5c03481aeda7804317e6d9efbb761399fe0e7b67
seriously ?
84 files changed in ONE commit ?
seriously ?
please do not blame Git if you guys have terrible workflows. This
would be even bigger mess with the Pharo VCS .
But this definitely not a good way to use Git or any VCS.
Let be serious here, I know you guys love Smalltalk
But common
A bit of common sense would not hurt.
If someone have sent me such a pull request I would have rejected it
in an instant without even looking at the code.
But if you guys like to deal with this kind of mess inside the Pharo
image, be my guest. I prefer the Git way of using Git and not the
"whatever" way and avoid the mess as much as possible.
One day (soon) the new tools (Iceberg ?) will allow me to do that,
allow me to see git as just an opaque back end, allow me to remain
inside the Pharo IDE (again, not that I can not or do not work in
a terminal, far from it, I just don't want to for my Pharo workflow)
So basically the mentality here is "give me Iceberg so I do not have
to learn Git or work like Git" , yeah good luck with that one.
I am not against Iceberg but I am sure it will be used as an excuse ,
like with many other things to bash Git and other non-Smalltalk
technologies, each time it fails.
You already compare Iceberg with using Git from the terminal. Of
course you will not mention SourceTree , GitUP, SmartGit , GitKraken
and a ton of other brilliant Git GUIs . Hell even Github offers its
own Git GUI client that makes using Git a breeze.
I think you greatly overestimate the opinion that people have about
Smalltalk, I can assure you its both positive and negative and VCS
falls under the negative category. I would like to see a community
that treats Smalltalk not as the holy grail.
The pull request example you used against Pharo and Git shows exactly
this kind of attitude , taking extremely bad situations that can be
easily be avoided as an excuse to present Smalltalk as "the superior
tool".
And when people do not bite the bait, you blame Smalltalk and
emphasize that Pharo is not really Smalltalk but Smalltalk inspired.
I have never been part of this ideology and will never going to be.
You guys are amazing and building a great tools, but in so many cases
you just lose touch with reality.
You ask me how many Smalltalkers agree with me, let me ask you how
many coders in general you think would agree with you ?
I am trying to avoid having this kind of discussions but on the other
hand I do not think all this denial is a good thing for Pharo.
Another thing I like to stress here, is that your goal to create a
self contained enviroment fully implemented in Smalltalk sorry I meant
Pharo, will not happens.
Gone are the times of 70, 80s and even 90s that a simple GUI could cut
it. Nowdays a modern coder uses a vast array of tools at his arsenal
because coding has become very complex to accomodate the high
expectations of modern users. We do not have the time, the money or
the community to build a tool that can compete on equal terms with the
ocean of tools that exist out there.
People do not use Git because they cannot use far simpler VCS , of
course not. They use because they know that projects grow and demands
changes and the time comes that they wish they have picked Git in the
first place because the more the project grows the more difficult it
becomes to switch VCS.
