We agree that we disagree, that's ok , we all have our own ways we like to work.
On Sat, 14 Jan 2017 at 17:08, Sven Van Caekenberghe <s...@stfx.eu> wrote: > We disagree, I should not have responded. > > > > Eclipse, IntelliJ, Emacs and so many other IDEs with massive user bases > all try to make things nice and easy to use inside their own IDE, to give > developers a cool, intelligent, language aware workflow. Of course Pharo > wants to do the same without being an island. > > > > Pharo/Smalltalk will never become a flat file based language. > > > > And yes, the pull request example was too big, but if it is only two minor > changes, any tool will do, if it is complex, all tools suffer, that is my > opinion. > > > > About your list of points: > > > > > My reason for not liking Monticello > > > a) GUI looks ugly > > > > Is an opinion > > > > > b) GUI opens needless windows (a generic Pharo problem) > > > > Is an opinion > > > > > c) No syntax highlighting in case of Browsing online code (diffs, > changes etc) > > > > An annoyance, not impossible to fix > > > > > d) No visualization of the commit history. > > > > Ok > > > > > e) the usual problems with documentation > > > > Not directly relevant here > > > > > f) No easy undo functionality > > > > Ok > > > > > g) Need to press a refresh button for monticello to be kept up to date > > > > An implementation detail > > > > > h) Monticello contacts irrelevant online repos even for local commits, > as a result a slow connection can freeze the image (WTF) > > > > It can be turned off, but yes it is annoying, although the reason for this > behaviour can be explained I also don't like this. > > > > > i) No clear indication of where the history branches and where it merges > > > > Same as d) > > > > This biggest issue is that it is not easy to get standard resources inside > MC. > > > > > > > On 14 Jan 2017, at 15:14, Dimitris Chloupis <kilon.al...@gmail.com> > wrote: > > > > > > > > > > > > On Sat, Jan 14, 2017 at 3:21 PM Sven Van Caekenberghe <s...@stfx.eu> > wrote: > > > > > > > On 14 Jan 2017, at 12:58, Dimitris Chloupis <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. > > > > > >
