Has anybody looked into SEO'ing any of the great documentation and archived questions on the mailing list? It strikes me that I often can't find the answer to questions I have on Google, but they are often answered in material that I can find when I look manually for some time or am pointed at it by an experienced member of the community. I also miss Pharo - content on Stackoverflow, it is a very efficient way to get past road blocks quickly. Any thoughts or history to bring me up to speed with? cheers, Siemen
Google already is capable on focusing on Pharo related websites. The core of our documentation is located on 3 websites World.st , this sites includes a forum website for all the Smalltalk related mailing lists Stackoverflow, Pharo has its own tag and a ton of answered questions Github.com, here are located all the Pharo books So to search all documentation about Spec on only these 3 websites you use the following search query pharo spec site:world.st OR site:stackoverflow.com OR site:github.com There are other ways to customize a google search query , please look at google search documentation On Thu, 12 Jan 2017 at 11:38, Siemen Baader <siemenbaader@gmail.com> wrote:
Has anybody looked into SEO'ing any of the great documentation and archived questions on the mailing list?
It strikes me that I often can't find the answer to questions I have on Google, but they are often answered in material that I can find when I look manually for some time or am pointed at it by an experienced member of the community.
I also miss Pharo - content on Stackoverflow, it is a very efficient way to get past road blocks quickly.
Any thoughts or history to bring me up to speed with?
cheers, Siemen
and slack is closed, right ?
On 13 Jan 2017, at 01:36, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
Google already is capable on focusing on Pharo related websites.
The core of our documentation is located on 3 websites
World.st , this sites includes a forum website for all the Smalltalk related mailing lists Stackoverflow, Pharo has its own tag and a ton of answered questions Github.com, here are located all the Pharo books
So to search all documentation about Spec on only these 3 websites you use the following search query
pharo spec site:world.st OR site:stackoverflow.com OR site:github.com
There are other ways to customize a google search query , please look at google search documentation On Thu, 12 Jan 2017 at 11:38, Siemen Baader <siemenbaader@gmail.com> wrote: Has anybody looked into SEO'ing any of the great documentation and archived questions on the mailing list?
It strikes me that I often can't find the answer to questions I have on Google, but they are often answered in material that I can find when I look manually for some time or am pointed at it by an experienced member of the community.
I also miss Pharo - content on Stackoverflow, it is a very efficient way to get past road blocks quickly.
Any thoughts or history to bring me up to speed with?
cheers, Siemen
Slack encrypts the message history and it only stores 10.000 messages You could use the Slack search feature https://get.slack.help/hc/en-us/articles/202528808-Search-for-messages-and-f... On Fri, 13 Jan 2017 at 08:40, Sven Van Caekenberghe <sven@stfx.eu> wrote:
and slack is closed, right ?
On 13 Jan 2017, at 01:36, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
Google already is capable on focusing on Pharo related websites.
The core of our documentation is located on 3 websites
World.st , this sites includes a forum website for all the Smalltalk related mailing lists
Stackoverflow, Pharo has its own tag and a ton of answered questions
Github.com, here are located all the Pharo books
So to search all documentation about Spec on only these 3 websites you use the following search query
pharo spec site:world.st OR site:stackoverflow.com OR site:github.com
There are other ways to customize a google search query , please look at google search documentation
On Thu, 12 Jan 2017 at 11:38, Siemen Baader <siemenbaader@gmail.com> wrote:
Has anybody looked into SEO'ing any of the great documentation and archived questions on the mailing list?
It strikes me that I often can't find the answer to questions I have on Google, but they are often answered in material that I can find when I look manually for some time or am pointed at it by an experienced member of the community.
I also miss Pharo - content on Stackoverflow, it is a very efficient way to get past road blocks quickly.
Any thoughts or history to bring me up to speed with?
cheers,
Siemen
so it is not publicly available/visible/indexable ? so everything written there basically disappears ?
On 13 Jan 2017, at 09:01, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
Slack encrypts the message history and it only stores 10.000 messages
You could use the Slack search feature
https://get.slack.help/hc/en-us/articles/202528808-Search-for-messages-and-f...
On Fri, 13 Jan 2017 at 08:40, Sven Van Caekenberghe <sven@stfx.eu> wrote: and slack is closed, right ?
On 13 Jan 2017, at 01:36, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
Google already is capable on focusing on Pharo related websites.
The core of our documentation is located on 3 websites
World.st , this sites includes a forum website for all the Smalltalk related mailing lists
Stackoverflow, Pharo has its own tag and a ton of answered questions
Github.com, here are located all the Pharo books
So to search all documentation about Spec on only these 3 websites you use the following search query
pharo spec site:world.st OR site:stackoverflow.com OR site:github.com
There are other ways to customize a google search query , please look at google search documentation
On Thu, 12 Jan 2017 at 11:38, Siemen Baader <siemenbaader@gmail.com> wrote:
Has anybody looked into SEO'ing any of the great documentation and archived questions on the mailing list?
It strikes me that I often can't find the answer to questions I have on Google, but they are often answered in material that I can find when I look manually for some time or am pointed at it by an experienced member of the community.
I also miss Pharo - content on Stackoverflow, it is a very efficient way to get past road blocks quickly.
Any thoughts or history to bring me up to speed with?
cheers,
Siemen
It eventually disappears , it keep the last 10.000 messages No it's not publicly visible quite the contrary , Slack prioritize privacy because it's meant to be used by teams working on commercial projects which are the ones more likely to pay for a slack subscription. If you want to search as a teams's history you need to gain access as a guest or a member , in both cases you will need an invite. So it makes little sense for Slack to give Google Acess to its teams history. If you as a team want to have unlimited messages then you will need to pay for the Slack subscription. Of course none can stop us from creating a bot that will copy the messages to an HTML website , that Google can search, hence lifting the 10k limit as well. Or even better commit those messages to a github repo that can be loaded as a project inside a Pharo image On Fri, 13 Jan 2017 at 10:05, Sven Van Caekenberghe <sven@stfx.eu> wrote:
so it is not publicly available/visible/indexable ?
so everything written there basically disappears ?
On 13 Jan 2017, at 09:01, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
Slack encrypts the message history and it only stores 10.000 messages
You could use the Slack search feature
https://get.slack.help/hc/en-us/articles/202528808-Search-for-messages-and-f...
On Fri, 13 Jan 2017 at 08:40, Sven Van Caekenberghe <sven@stfx.eu> wrote:
and slack is closed, right ?
On 13 Jan 2017, at 01:36, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
Google already is capable on focusing on Pharo related websites.
The core of our documentation is located on 3 websites
World.st , this sites includes a forum website for all the Smalltalk related mailing lists
Stackoverflow, Pharo has its own tag and a ton of answered questions
Github.com, here are located all the Pharo books
So to search all documentation about Spec on only these 3 websites you use the following search query
pharo spec site:world.st OR site:stackoverflow.com OR site:github.com
There are other ways to customize a google search query , please look at google search documentation
On Thu, 12 Jan 2017 at 11:38, Siemen Baader <siemenbaader@gmail.com> wrote:
Has anybody looked into SEO'ing any of the great documentation and archived questions on the mailing list?
It strikes me that I often can't find the answer to questions I have on Google, but they are often answered in material that I can find when I look manually for some time or am pointed at it by an experienced member of the community.
I also miss Pharo - content on Stackoverflow, it is a very efficient way to get past road blocks quickly.
Any thoughts or history to bring me up to speed with?
cheers,
Siemen
so it is not a good idea for an open source project, as I feared.
On 13 Jan 2017, at 09:15, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
It eventually disappears , it keep the last 10.000 messages
No it's not publicly visible quite the contrary , Slack prioritize privacy because it's meant to be used by teams working on commercial projects which are the ones more likely to pay for a slack subscription.
If you want to search as a teams's history you need to gain access as a guest or a member , in both cases you will need an invite. So it makes little sense for Slack to give Google Acess to its teams history.
If you as a team want to have unlimited messages then you will need to pay for the Slack subscription.
Of course none can stop us from creating a bot that will copy the messages to an HTML website , that Google can search, hence lifting the 10k limit as well. Or even better commit those messages to a github repo that can be loaded as a project inside a Pharo image On Fri, 13 Jan 2017 at 10:05, Sven Van Caekenberghe <sven@stfx.eu> wrote: so it is not publicly available/visible/indexable ?
so everything written there basically disappears ?
On 13 Jan 2017, at 09:01, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
Slack encrypts the message history and it only stores 10.000 messages
You could use the Slack search feature
https://get.slack.help/hc/en-us/articles/202528808-Search-for-messages-and-f...
On Fri, 13 Jan 2017 at 08:40, Sven Van Caekenberghe <sven@stfx.eu> wrote:
and slack is closed, right ?
On 13 Jan 2017, at 01:36, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
Google already is capable on focusing on Pharo related websites.
The core of our documentation is located on 3 websites
World.st , this sites includes a forum website for all the Smalltalk related mailing lists
Stackoverflow, Pharo has its own tag and a ton of answered questions
Github.com, here are located all the Pharo books
So to search all documentation about Spec on only these 3 websites you use the following search query
pharo spec site:world.st OR site:stackoverflow.com OR site:github.com
There are other ways to customize a google search query , please look at google search documentation
On Thu, 12 Jan 2017 at 11:38, Siemen Baader <siemenbaader@gmail.com> wrote:
Has anybody looked into SEO'ing any of the great documentation and archived questions on the mailing list?
It strikes me that I often can't find the answer to questions I have on Google, but they are often answered in material that I can find when I look manually for some time or am pointed at it by an experienced member of the community.
I also miss Pharo - content on Stackoverflow, it is a very efficient way to get past road blocks quickly.
Any thoughts or history to bring me up to speed with?
cheers,
Siemen
Neither is IRC but that has not stopped irc users from creating bots that keep track of a irc channel's message history in logs that are automatically uploaded to websites searchable by google. Unlike Slack , IRC is even worse not even it does not store the last 10k messages , it does not even store ANY message , yet it's by very far the most popular chat client for open source projects Proving that even the worse idea can be turned to the best idea very easily On Fri, 13 Jan 2017 at 10:18, Sven Van Caekenberghe <sven@stfx.eu> wrote:
so it is not a good idea for an open source project, as I feared.
On 13 Jan 2017, at 09:15, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
It eventually disappears , it keep the last 10.000 messages
No it's not publicly visible quite the contrary , Slack prioritize privacy because it's meant to be used by teams working on commercial projects which are the ones more likely to pay for a slack subscription.
If you want to search as a teams's history you need to gain access as a guest or a member , in both cases you will need an invite. So it makes little sense for Slack to give Google Acess to its teams history.
If you as a team want to have unlimited messages then you will need to pay for the Slack subscription.
Of course none can stop us from creating a bot that will copy the messages to an HTML website , that Google can search, hence lifting the 10k limit as well. Or even better commit those messages to a github repo that can be loaded as a project inside a Pharo image On Fri, 13 Jan 2017 at 10:05, Sven Van Caekenberghe <sven@stfx.eu> wrote: so it is not publicly available/visible/indexable ?
so everything written there basically disappears ?
On 13 Jan 2017, at 09:01, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
Slack encrypts the message history and it only stores 10.000 messages
You could use the Slack search feature
https://get.slack.help/hc/en-us/articles/202528808-Search-for-messages-and-f...
On Fri, 13 Jan 2017 at 08:40, Sven Van Caekenberghe <sven@stfx.eu> wrote:
and slack is closed, right ?
On 13 Jan 2017, at 01:36, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
Google already is capable on focusing on Pharo related websites.
The core of our documentation is located on 3 websites
World.st , this sites includes a forum website for all the Smalltalk related mailing lists
Stackoverflow, Pharo has its own tag and a ton of answered questions
Github.com, here are located all the Pharo books
So to search all documentation about Spec on only these 3 websites you use the following search query
pharo spec site:world.st OR site:stackoverflow.com OR site: github.com
There are other ways to customize a google search query , please look at google search documentation
On Thu, 12 Jan 2017 at 11:38, Siemen Baader <siemenbaader@gmail.com> wrote:
Has anybody looked into SEO'ing any of the great documentation and archived questions on the mailing list?
It strikes me that I often can't find the answer to questions I have on Google, but they are often answered in material that I can find when I look manually for some time or am pointed at it by an experienced member of the community.
I also miss Pharo - content on Stackoverflow, it is a very efficient way to get past road blocks quickly.
Any thoughts or history to bring me up to speed with?
cheers,
Siemen
Sven Van Caekenberghe-2 wrote
so it is not a good idea for an open source project, as I feared.
+1. I was concerned from the beginning that our conversations would get more fragmented. I rarely have time to check slack and the mailing list recently seems to be missing quite a bit of deliberation that's happening elsewhere. My 2c ----- Cheers, Sean -- View this message in context: http://forum.world.st/Google-visibility-tp4929414p4929660.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
On Sun, 15 Jan 2017 06:22:59 +0100, Sean P. DeNigris <sean@clipperadams.com> wrote:
Sven Van Caekenberghe-2 wrote
so it is not a good idea for an open source project, as I feared.
+1. I was concerned from the beginning that our conversations would get more fragmented. I rarely have time to check slack and the mailing list recently seems to be missing quite a bit of deliberation that's happening elsewhere.
I agree same for me. I cannot be connected all the time. I prefer emails because I can consume them the way I want. Stef
My 2c
----- Cheers, Sean -- View this message in context: http://forum.world.st/Google-visibility-tp4929414p4929660.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
-- Using Opera's mail client: http://www.opera.com/mail/
Steph, Sven, Sean and everybody else, Am 15.01.17 um 09:41 schrieb stepharong:
On Sun, 15 Jan 2017 06:22:59 +0100, Sean P. DeNigris <sean@clipperadams.com> wrote:
Sven Van Caekenberghe-2 wrote
so it is not a good idea for an open source project, as I feared.
+1. I was concerned from the beginning that our conversations would get more fragmented. I rarely have time to check slack and the mailing list recently seems to be missing quite a bit of deliberation that's happening elsewhere.
I agree same for me. I cannot be connected all the time. I prefer emails because I can consume them the way I want.
And that's exactly why I still like the usenet: I can read/answer whenever I want, using my mail client (opera, thunderbird) and all is archived and can be searched from within the mail client or by a search engine, Usenet is a central place, accessible to anybody, anytime, and you don't have to search for mailing lists and go through strange opt-in/out mail exchanges, What was actually wrong with comp.lang.smalltalk and subforums that could only be fixed by opening new sites and mailing lists and whatnot that more or less all look abandoned these days? Joachim
I like interacting with the news group too, including with this mailing list. I found it very efficient. Hilaire Le 15/01/2017 à 09:46, jtuchel@objektfabrik.de a écrit :
And that's exactly why I still like the usenet: I can read/answer whenever I want, using my mail client (opera, thunderbird) and all is archived and can be searched from within the mail client or by a search engine, Usenet is a central place, accessible to anybody, anytime, and you don't have to search for mailing lists and go through strange opt-in/out mail exchanges,
What was actually wrong with comp.lang.smalltalk and subforums that could only be fixed by opening new sites and mailing lists and whatnot that more or less all look abandoned these days?
-- Dr. Geo http://drgeo.eu
On Sun, Jan 15, 2017 at 6:22 AM, Sean P. DeNigris <sean@clipperadams.com> wrote:
Sven Van Caekenberghe-2 wrote
so it is not a good idea for an open source project, as I feared.
+1. I was concerned from the beginning that our conversations would get more fragmented. I rarely have time to check slack and the mailing list recently seems to be missing quite a bit of deliberation that's happening elsewhere.
Amost all of the chatter happens on Slack. That's a fact. Less friction, more immediate feedback, ability to copy/paste snippets and pictures. Now, letting all of this in a forgetful back hole is a shame. Phil
My 2c
----- Cheers, Sean -- View this message in context: http://forum.world.st/Google- visibility-tp4929414p4929660.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
I created Discord chat channel for this precise reason but it has its own disadvantages like lack of search facility I have to agree with Hillary , mailing lists is by far the most efficient way of solving problems and is not even any slower than the online chat and far easier for someone to spot your question than in a waterfall of online chat messages. I find it impossible to keep track of what is happening on Slack sometimes and cant be bothered to organise it. On Sun, Jan 15, 2017 at 3:18 PM phil@highoctane.be <phil@highoctane.be> wrote:
On Sun, Jan 15, 2017 at 6:22 AM, Sean P. DeNigris <sean@clipperadams.com> wrote:
Sven Van Caekenberghe-2 wrote
so it is not a good idea for an open source project, as I feared.
+1. I was concerned from the beginning that our conversations would get more fragmented. I rarely have time to check slack and the mailing list recently seems to be missing quite a bit of deliberation that's happening elsewhere.
Amost all of the chatter happens on Slack. That's a fact. Less friction, more immediate feedback, ability to copy/paste snippets and pictures. Now, letting all of this in a forgetful back hole is a shame.
Phil
My 2c
----- Cheers, Sean -- View this message in context: http://forum.world.st/Google-visibility-tp4929414p4929660.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
unless we pay. they basically kidnap our messages and demand a ransom for them (and is expensive)⦠and the model seems to work, everybody prefers using that than a searchable tool :( I would prefer to use an open tool, but well⦠slack gives us a lot of features and life is like this :( Esteban
On 13 Jan 2017, at 09:04, Sven Van Caekenberghe <sven@stfx.eu> wrote:
so it is not publicly available/visible/indexable ? so everything written there basically disappears ?
On 13 Jan 2017, at 09:01, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
Slack encrypts the message history and it only stores 10.000 messages
You could use the Slack search feature
https://get.slack.help/hc/en-us/articles/202528808-Search-for-messages-and-f...
On Fri, 13 Jan 2017 at 08:40, Sven Van Caekenberghe <sven@stfx.eu> wrote: and slack is closed, right ?
On 13 Jan 2017, at 01:36, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
Google already is capable on focusing on Pharo related websites.
The core of our documentation is located on 3 websites
World.st , this sites includes a forum website for all the Smalltalk related mailing lists
Stackoverflow, Pharo has its own tag and a ton of answered questions
Github.com, here are located all the Pharo books
So to search all documentation about Spec on only these 3 websites you use the following search query
pharo spec site:world.st OR site:stackoverflow.com OR site:github.com
There are other ways to customize a google search query , please look at google search documentation
On Thu, 12 Jan 2017 at 11:38, Siemen Baader <siemenbaader@gmail.com> wrote:
Has anybody looked into SEO'ing any of the great documentation and archived questions on the mailing list?
It strikes me that I often can't find the answer to questions I have on Google, but they are often answered in material that I can find when I look manually for some time or am pointed at it by an experienced member of the community.
I also miss Pharo - content on Stackoverflow, it is a very efficient way to get past road blocks quickly.
Any thoughts or history to bring me up to speed with?
cheers,
Siemen
There are open source alternatives This https://rocket.chat And this https://riot.im/app/#/directory On Fri, 13 Jan 2017 at 10:26, Esteban Lorenzano <estebanlm@gmail.com> wrote:
unless we pay. they basically kidnap our messages and demand a ransom for them (and is expensive)⦠and the model seems to work, everybody prefers using that than a searchable tool :(
I would prefer to use an open tool, but well⦠slack gives us a lot of features and life is like this :(
Esteban
On 13 Jan 2017, at 09:04, Sven Van Caekenberghe <sven@stfx.eu> wrote:
so it is not publicly available/visible/indexable ? so everything written there basically disappears ?
On 13 Jan 2017, at 09:01, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
Slack encrypts the message history and it only stores 10.000 messages
You could use the Slack search feature
https://get.slack.help/hc/en-us/articles/202528808-Search-for-messages-and-f...
On Fri, 13 Jan 2017 at 08:40, Sven Van Caekenberghe <sven@stfx.eu>
wrote:
and slack is closed, right ?
On 13 Jan 2017, at 01:36, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
Google already is capable on focusing on Pharo related websites.
The core of our documentation is located on 3 websites
World.st , this sites includes a forum website for all the Smalltalk related mailing lists
Stackoverflow, Pharo has its own tag and a ton of answered questions
Github.com, here are located all the Pharo books
So to search all documentation about Spec on only these 3 websites you use the following search query
pharo spec site:world.st OR site:stackoverflow.com OR site:github.com
There are other ways to customize a google search query , please look at google search documentation
On Thu, 12 Jan 2017 at 11:38, Siemen Baader <siemenbaader@gmail.com> wrote:
Has anybody looked into SEO'ing any of the great documentation and archived questions on the mailing list?
It strikes me that I often can't find the answer to questions I have on Google, but they are often answered in material that I can find when I look manually for some time or am pointed at it by an experienced member of the community.
I also miss Pharo - content on Stackoverflow, it is a very efficient way to get past road blocks quickly.
Any thoughts or history to bring me up to speed with?
cheers,
Siemen
Am 13.01.17 um 09:25 schrieb Esteban Lorenzano:
unless we pay. they basically kidnap our messages and demand a ransom for them (and is expensive)⦠and the model seems to work, everybody prefers using that than a searchable tool :( no, you give them to them for free and liberally. People don't understand the difference and tend to shout out: bad guys, we need more laws!
I would prefer to use an open tool, but well⦠slack gives us a lot of features and life is like this :(
Is the usenet still around? It had all of what you ask for, without the colors and emojis, though. The ones from my generation may remember comp.lang.smalltalk and subforums. It was a great way to publicly discuss things... Sorry for this, but I couldn't hold it back. .. and please, be careful before you shout: Google groups!
Joachim
... it's official now: I don't know the difference between discussion groups and a chat.... So forget my last post, or simply accept that I'm not a chat fan. Often enough, I hardly understand what I am talking about, so a typical chat session is far beyond my horizon ;-) Joachim
Am 13.01.2017 um 09:36 schrieb jtuchel@objektfabrik.de:
... it's official now: I don't know the difference between discussion groups and a chat....
So forget my last post, or simply accept that I'm not a chat fan. Often enough, I hardly understand what I am talking about, so a typical chat session is far beyond my horizon ;-)
So, the chat might be exactly the medium for you because you can edit messages afterwards ;) Norbert
"Is the usenet still around? It had all of what you ask for, without the colors and emojis, though" Everything is still around and kicking, usenets , bbs , Amiga, Amstrad, Atari , dos and a much more All of the actively developed with colors, emojis , acess to internet, 3D graphics, movies, sound, music and integrated with many modern technologies because vintage will always be super cool and enjoyable It may surprise Pharo developers since for many of them is kinda like a taboo to a admit the true age of Pharo legacy code, but there a ton of people that prefer the simplicity and elegance of 30 year old technology over new technology anyway. Obviously because they are aware how easy it is to integrate old with new. I was recently at the Athens comic con festival and one of the main attractions was an area dedicated to vintage computers and consoles with a very active community, they were even televised because they allowed anyone to use these computers and because the con was a huge success . I was pleasantly surprise to see people who enjoyed using these computers were not people raised with amigas and Amstrad and ataris but also kids raised with modern pcs , PS4 , Xbox one etc. Showing that anyone can enjoy old technology.
Okay, now that I helped hitchhike this thread into completely different spheres... ;-) I don't think this is only a question of enjoying old tech or vintage fanboyhood. It is also about questonable added value of new technologies. I remember the days when all my newsgroups were in my Mail client (opera or thunderbird). Stuff was easy and you could search stuff. Everything was in one place., be it chess related, car repair tips or computing stuff. I used the same GUI for all of that. And everybody went there, not to a number of othjer places. These days we use StackOverflow. Or ServerFault. Or Google+/Groups. Or Facebook, or Xing or Twitter or you name it. Sure, we have bots to copy everything from everywhere to anywehre else. But, hey, where's the value of this. Even worse: if somebody happens to drop by comp.lang.smalltalk, they must have the impression this is a long gone technology, because we now discuss elsewhere and left that space to pill and investment bandits and trolls. But, hey, we're off-topic now.... Joachim ;-) Am 13.01.17 um 09:58 schrieb Dimitris Chloupis:
"Is the usenet still around? It had all of what you ask for, without the
colors and emojis, though"
Everything is still around and kicking, usenets , bbs , Amiga, Amstrad, Atari , dos and a much more
All of the actively developed with colors, emojis , acess to internet, 3D graphics, movies, sound, music and integrated with many modern technologies because vintage will always be super cool and enjoyable
It may surprise Pharo developers since for many of them is kinda like a taboo to a admit the true age of Pharo legacy code, but there a ton of people that prefer the simplicity and elegance of 30 year old technology over new technology anyway. Obviously because they are aware how easy it is to integrate old with new.
I was recently at the Athens comic con festival and one of the main attractions was an area dedicated to vintage computers and consoles with a very active community, they were even televised because they allowed anyone to use these computers and because the con was a huge success .
I was pleasantly surprise to see people who enjoyed using these computers were not people raised with amigas and Amstrad and ataris but also kids raised with modern pcs , PS4 , Xbox one etc. Showing that anyone can enjoy old technology.
-- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
On Fri, Jan 13, 2017 at 11:12 AM jtuchel@objektfabrik.de < jtuchel@objektfabrik.de> wrote: I remember the days when all my newsgroups were in my Mail client (opera or thunderbird). Stuff was easy and you could search stuff. Everything was in one place., be it chess related, car repair tips or computing stuff. I used the same GUI for all of that. And everybody went there, not to a number of othjer places. These days we use StackOverflow. Or ServerFault. Or Google+/Groups. Or Facebook, or Xing or Twitter or you name it. Sure, we have bots to copy everything from everywhere to anywehre else. But, hey, where's the value of this. Even worse: if somebody happens to drop by comp.lang.smalltalk, they must have the impression this is a long gone technology, because we now discuss elsewhere and left that space to pill and investment bandits and trolls Google Groups .... seriously ? Google groups were never popular and practically almost none cares about it, its one the thousands failed abandonware products of Google. G+ is not in a much better state either. Mailing lists and IRC is still by far the most popular with open source projects. Anything else is far less. " But, hey, we're off-topic now.... Joachim ;-) " Essentially the title of the thread is "what I can search pharo related with google search" .... so , no we are not. In order to be off topic we will have to discuss something that is not pharo and google search related. So let me rest assure you , you are way on topic, nothing to worry about. Actually I have to thank you because with Google Groups you reminded me another site to add to that google search query, Reddit. Not as active as world.st but active enough , so add that to that query pharo spec site:world.st OR site:stackoverflow.com OR site:github.com OR site:reddit.com/r/smalltalk/
To be honest, I think our answer doesn't really fit to the original post ;-) The OP wanted to express their worries about the fact that it is not easy to find content for Pharo, even though it is there. This is more a critique that says: the content is hard to find if you just know a keyword to look for. As soon as I know I have to enter this into Google: pharo spec site:world.st <http://world.st/>OR site:stackoverflow.com <http://stackoverflow.com/>OR site:github.com <http://github.com/> OR site:reddit.com/r/smalltalk/ <http://reddit.com/r/smalltalk/> I am in the lucky position to not need that know how anymore, because I know the places. It's like "once you are in front of the store, you'll know how to find it!". ;-) So the topic of this thread is that maybe some SEO is needed rather than educating people in searching better ;-) So we were both off-topic like hell ;-) Joachim
On Fri, Jan 13, 2017 at 11:14 AM, jtuchel@objektfabrik.de < jtuchel@objektfabrik.de> wrote:
To be honest, I think our answer doesn't really fit to the original post ;-)
It's like "once you are in front of the store, you'll know how to find it!". ;-)
So the topic of this thread is that maybe some SEO is needed rather than educating people in searching better ;-)
Yes, that was my point.. Thanks for the discussion though :) Perhaps it would make sense to add that custom search to Pharo.org. I looked into it, but it seemed that one has to pay for that.. Maybe am wrong. -- Siemen
I though that my example made this clear, apparently it did not so let me try again. No SEO is not a problem SEO is not a problem because we have made the smart move as a community to host our projects and discussions and documentation to existing google friendly websites like Github, world.st and stackoverflow. As such its very easy to find documentation about Pharo. The problem here is what makes Google special, what made it the No1 search engine. You see before Google there was this search engine called AltaVista, AltaVista was doing what is relevant to a SEO , it was basically searching for sites and bringing up accurate search results . So if Google search was doing just that we will still be using AltaVista and Google would have never existed. However what Google devs did that made a huge diffirence was to design an algorithm using AI techniques that not only returned accurate results but also related results. This made it possible to withstand spelling errors or differentiate between search results using the same name etc. Also customised the experience by keeping track of user's preferences via google analytics. As such this poses a problem, that Google not only is able to find a vast majority of the Pharo documentation because as I said we host it in websites taking advantage of SEO but also related info. This poses a problem because Google mixes up pharo results with pharao results, or maybe its still pharo but its a book, or a music band etc. The query I provided eliminates a problem that SEO cannot eliminate , removing the search results that is highly likely to not be related to OUR pharo. However even if this query provides a nice solution it is not waterproof. For example it does not include many of the blogs that keep track of pharo progress and document many of its parts. For example Ben recently posted a very nice guide for UFFI. Also there is no need for this query if you search for specific class or method names since its far less likely that Google will return irrelevant results. Also another problem is the rapid improvement of Pharo, this something begineers are not aware because its easy to underestimate how fast Pharo is moving mainly because of the fact is not popular. But Pharo moves forward very fast. So fast that is easy to fall in the trap of finding the right method and right class but not the up to date version, thus you need also date and time based search as well that google also provides. Also you may prefer to find PDFs because you will like a guide or in depth tutorial instead of some random discussion , or a two pages tutorial in that case you will add to the query filteype:PDF and so on Learning how to search with Google is an art by itself and no bringing it inside the Pharo image wont make a big difference to newcomers because we still need to implement a complex GUI to accommodate for many different needs. So we will be wasting time recreating Google inside the Pharo image and you will be using a tool that still requires to learn things similar what you need to learn for using Google search. No matter the language you are learning the workflow is similar, start with a beginner friendly guide or book, join a forum and ask for directions, take a look at youtube tutorials and learn how to use Google. Pharo or no Pharo, you will lose a great deal of efficiency if you do not learn how to use Google. So no we do not need to SEO world.st , stackoverflow, github , or slideshare they are doing a pretty good job Smalltalkhub and blog posts may not be SEO but a) Smalltalkhub is a dead project no longer maintained other than making sure the server is online b) we cannot force people to SEO their blogs, thats up to them
On 01/13/2017 01:01 PM, Dimitris Chloupis wrote:
For example Ben recently posted a very nice guide for UFFI.
Hi, where do i find Bens blog? i think it is not mentioned at http://pharo.org/web/blogs . btw another very informative blog about pharo, not mentioned there, is Peters https://www.peteruhnak.com/blog/ werner
Oh, and then there are really helpful articles on medium
Am 13.01.2017 um 13:54 schrieb werner kassens <wkassens@libello.com>:
On 01/13/2017 01:01 PM, Dimitris Chloupis wrote: For example Ben recently posted a very nice guide for UFFI.
Hi, where do i find Bens blog? i think it is not mentioned at http://pharo.org/web/blogs . btw another very informative blog about pharo, not mentioned there, is Peters https://www.peteruhnak.com/blog/ werner
Yes Sven posts some really nice pharo articles in his medium blog from time to time https://medium.com/concerning-pharo On Fri, Jan 13, 2017 at 3:00 PM Joachim Tuchel <jtuchel@objektfabrik.de> wrote:
Oh, and then there are really helpful articles on medium
Am 13.01.2017 um 13:54 schrieb werner kassens <wkassens@libello.com>:
On 01/13/2017 01:01 PM, Dimitris Chloupis wrote: For example Ben recently posted a very nice guide for UFFI.
Hi, where do i find Bens blog? i think it is not mentioned at http://pharo.org/web/blogs . btw another very informative blog about pharo, not mentioned there, is Peters https://www.peteruhnak.com/blog/ werner
On 13 Jan 2017, at 14:17, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
Yes Sven posts some really nice pharo articles in his medium blog from time to time
'Concerning Pharo' is what is called a 'Publication' on Medium.com, it is a grouping of articles by multiple authors. Most are mine, and I am the owner/editor, but I am very happy that others allowed me to include their great articles as well: - Torsten Bergmann - Julien Delplanque - Stephan Eggermont I hope that others will join: it is very easy and very pleasant to write an article on Medium.com, but above all it is very important that more long form documentation about Pharo gets written and promoted. Sven
On Fri, Jan 13, 2017 at 3:00 PM Joachim Tuchel <jtuchel@objektfabrik.de> wrote: Oh, and then there are really helpful articles on medium
Am 13.01.2017 um 13:54 schrieb werner kassens <wkassens@libello.com>:
On 01/13/2017 01:01 PM, Dimitris Chloupis wrote: For example Ben recently posted a very nice guide for UFFI.
Hi, where do i find Bens blog? i think it is not mentioned at http://pharo.org/web/blogs . btw another very informative blog about pharo, not mentioned there, is Peters https://www.peteruhnak.com/blog/ werner
here you go http://blog.openinworld.com/author/admin/ On Fri, Jan 13, 2017 at 2:55 PM werner kassens <wkassens@libello.com> wrote:
On 01/13/2017 01:01 PM, Dimitris Chloupis wrote:
For example Ben recently posted a very nice guide for UFFI.
Hi, where do i find Bens blog? i think it is not mentioned at http://pharo.org/web/blogs . btw another very informative blog about pharo, not mentioned there, is Peters https://www.peteruhnak.com/blog/ werner
Hi, On custom searches, I know that duckduckgo[1] has a program for developers. Now is focused on popular languages, but maybe we could put our own search button in pharo.org to provide that custom search that harvest the Pharo community intelligence. That could be a project for a small Pharo hackathon. [1] https://duckduckhack.com/ On ransomware (I will hold the data you provide me until you pay), yes, the problem was that we did not start to use FLOSS alternatives before, mostly because of the effort to setup and maintain them and migration is costly now. As a small community, addressing that problems to have our own infrastructure (or scrapping others infrastructure) is expensive, so we're using gratis infrastructure that cost our collective memory in the long term. On STHub, fortunately is live enough to let some of us being productive without the noise of git in front. Cheers, Offray On 13/01/17 07:01, Dimitris Chloupis wrote:
I though that my example made this clear, apparently it did not so let me try again.
No SEO is not a problem
SEO is not a problem because we have made the smart move as a community to host our projects and discussions and documentation to existing google friendly websites like Github, world.st <http://world.st> and stackoverflow.
As such its very easy to find documentation about Pharo.
The problem here is what makes Google special, what made it the No1 search engine.
You see before Google there was this search engine called AltaVista, AltaVista was doing what is relevant to a SEO , it was basically searching for sites and bringing up accurate search results . So if Google search was doing just that we will still be using AltaVista and Google would have never existed.
However what Google devs did that made a huge diffirence was to design an algorithm using AI techniques that not only returned accurate results but also related results. This made it possible to withstand spelling errors or differentiate between search results using the same name etc. Also customised the experience by keeping track of user's preferences via google analytics.
As such this poses a problem, that Google not only is able to find a vast majority of the Pharo documentation because as I said we host it in websites taking advantage of SEO but also related info. This poses a problem because Google mixes up pharo results with pharao results, or maybe its still pharo but its a book, or a music band etc.
The query I provided eliminates a problem that SEO cannot eliminate , removing the search results that is highly likely to not be related to OUR pharo.
However even if this query provides a nice solution it is not waterproof. For example it does not include many of the blogs that keep track of pharo progress and document many of its parts. For example Ben recently posted a very nice guide for UFFI.
Also there is no need for this query if you search for specific class or method names since its far less likely that Google will return irrelevant results.
Also another problem is the rapid improvement of Pharo, this something begineers are not aware because its easy to underestimate how fast Pharo is moving mainly because of the fact is not popular.
But Pharo moves forward very fast.
So fast that is easy to fall in the trap of finding the right method and right class but not the up to date version, thus you need also date and time based search as well that google also provides.
Also you may prefer to find PDFs because you will like a guide or in depth tutorial instead of some random discussion , or a two pages tutorial in that case you will add to the query
filteype:PDF
and so on
Learning how to search with Google is an art by itself and no bringing it inside the Pharo image wont make a big difference to newcomers because we still need to implement a complex GUI to accommodate for many different needs. So we will be wasting time recreating Google inside the Pharo image and you will be using a tool that still requires to learn things similar what you need to learn for using Google search.
No matter the language you are learning the workflow is similar, start with a beginner friendly guide or book, join a forum and ask for directions, take a look at youtube tutorials and learn how to use Google.
Pharo or no Pharo, you will lose a great deal of efficiency if you do not learn how to use Google.
So no we do not need to SEO world.st <http://world.st> , stackoverflow, github , or slideshare they are doing a pretty good job
Smalltalkhub and blog posts may not be SEO but a) Smalltalkhub is a dead project no longer maintained other than making sure the server is online b) we cannot force people to SEO their blogs, thats up to them
On 14 Jan 2017, at 00:48, Offray Vladimir Luna Cárdenas <offray.luna@mutabit.com> wrote:
On STHub, fortunately is live enough to let some of us being productive without the noise of git in front.
So true. Let's stop bashing StHub: it works fine for 1000s of projects. I know we are building something new and I am all for it, but as long as it is not as user friendly as Monticello (all operations clean and simple in Pharo, reliably) we are not there yet. The point is: we all know how to use git, but most Pharo developers don't want to deal with file based Pharo code, at all, ever. Sven
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. StHub on the other hand is whole different situation. My criticism about StHub unlike Monticello are not opinion based, they are fact based, StHub is unmaintaned , with the usual failures prompting Esteban to reset the whole thing and lacking the most fundamental features like a sophisticated search facility and any form of browsing. I could go on, but I think the shortcomings are obvious. That's no bashing, its a statement of facts. On the subject of file based code, I wonder what you use for Pharo VCS because the default Pharo VCS is basically zip (mcz extension) files containing source code files , the usual text files with the "st" extension. If you mean the fact of actually worrying about the files themselves, the only worrying you do with Git is for the gitignore file (if you actually use one) that basically there can be listed what files or directories should be ignored by Git. The rest are done automagically by Filetree, GitFileTree or in my case my Git GUI client. I also never said "Do not use Pharo VCS" , if that is what rocks your boat, but to actual claim that Pharo VCS is more reliable, easier to use and more powerful would require a huge leap of faith because from the very first experience it pretty crystal clear that is not. And there is not just Git, there are plenty of other VCS out there that are just light years ahead, some probably better than Git. But I have no problem if some people prefer to use the old VCS instead of Git. I am not here to impose my workflow and I never stated that we should. As a matter of fact I do not mind any choice the community makes as long as I have freedom to choose my own tools and my own workflow. On Sat, Jan 14, 2017 at 11:10 AM Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 14 Jan 2017, at 00:48, Offray Vladimir Luna Cárdenas < offray.luna@mutabit.com> wrote:
On STHub, fortunately is live enough to let some of us being productive without the noise of git in front.
So true.
Let's stop bashing StHub: it works fine for 1000s of projects. I know we are building something new and I am all for it, but as long as it is not as user friendly as Monticello (all operations clean and simple in Pharo, reliably) we are not there yet.
The point is: we all know how to use git, but most Pharo developers don't want to deal with file based Pharo code, at all, ever.
Sven
On 14 Jan 2017, at 12:58, Dimitris Chloupis <kilon.alios@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. 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. Is it perfect ? Does it have all features ? No, of course not. Remember that we have total control over its model and implementation in code.
StHub on the other hand is whole different situation.
My criticism about StHub unlike Monticello are not opinion based, they are fact based, StHub is unmaintaned , with the usual failures prompting Esteban to reset the whole thing and lacking the most fundamental features like a sophisticated search facility and any form of browsing. I could go on, but I think the shortcomings are obvious. That's no bashing, its a statement of facts.
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. Do I want something better ? Sure, people are working on that.
On the subject of file based code, I wonder what you use for Pharo VCS because the default Pharo VCS is basically zip (mcz extension) files containing source code files , the usual text files with the "st" extension. If you mean the fact of actually worrying about the files themselves, the only worrying you do with Git is for the gitignore file (if you actually use one) that basically there can be listed what files or directories should be ignored by Git. The rest are done automagically by Filetree, GitFileTree or in my case my Git GUI client.
No normal user looks or needs to look inside .mcz files. That is the whole point, it is based on a model/abstraction visible/manipulated in the IDE only. Again, I know git, I use git, even for Pharo. But the current approach is not good enough and it is far from stable or user friendly enough for prime time (I don't mean that git, GitHub or any other git tool is not good, I am talking about the interface with the Pharo IDE and workflow). 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 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). Still, MC and its classic repositories will remain with us for a long time.
I also never said "Do not use Pharo VCS" , if that is what rocks your boat, but to actual claim that Pharo VCS is more reliable, easier to use and more powerful would require a huge leap of faith because from the very first experience it pretty crystal clear that is not.
And there is not just Git, there are plenty of other VCS out there that are just light years ahead, some probably better than Git.
I disagree.
But I have no problem if some people prefer to use the old VCS instead of Git. I am not here to impose my workflow and I never stated that we should.
As a matter of fact I do not mind any choice the community makes as long as I have freedom to choose my own tools and my own workflow.
I am pretty sure all options will remain open.
On Sat, Jan 14, 2017 at 11:10 AM Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 14 Jan 2017, at 00:48, Offray Vladimir Luna Cárdenas <offray.luna@mutabit.com> wrote:
On STHub, fortunately is live enough to let some of us being productive without the noise of git in front.
So true.
Let's stop bashing StHub: it works fine for 1000s of projects. I know we are building something new and I am all for it, but as long as it is not as user friendly as Monticello (all operations clean and simple in Pharo, reliably) we are not there yet.
The point is: we all know how to use git, but most Pharo developers don't want to deal with file based Pharo code, at all, ever.
Sven
On Sat, Jan 14, 2017 at 3:21 PM Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 14 Jan 2017, at 12:58, Dimitris Chloupis <kilon.alios@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/5c03481aeda7804317e6d9efbb761... 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.
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.alios@gmail.com> wrote:
On Sat, Jan 14, 2017 at 3:21 PM Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 14 Jan 2017, at 12:58, Dimitris Chloupis <kilon.alios@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/5c03481aeda7804317e6d9efbb761...
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.
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 <sven@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.alios@gmail.com> wrote:
On Sat, Jan 14, 2017 at 3:21 PM Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 14 Jan 2017, at 12:58, Dimitris Chloupis <kilon.alios@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
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/5c03481aeda7804317e6d9efbb761...
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.
On 14/01/17 09:14, Dimitris Chloupis wrote: [...]
Remember we have to compete with languages like Ruby and Python .
[...] And in the live coding and moldability camp the competition goes pretty well (Ruby has Sonic Pi, Python has Jupyter, for other audience, but none of those are as moldable as Pharo or bring so much liveness to coding, and not all competition is for the soul and heart of developers, there is a wider world were we can offer a pretty interesting value proposal
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.
I agree with not having git in front. So yes, I will wait for Iceberg and will use StHub as much as I can. I share that Smalltalk and Pharo need to be less insular, by supporting external technologies and formats (git, markdown, etc), but the experience should be as smooth as possible and we need ways to map the live coding experience to that external world.
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.
I don't know if denial is the proper world. I have said before I do not want become part of a holy war anytime someone mentions a DVCS that is not git or markup that is no pillar and so on, but I think that we, as a community are getting better at increasing diversity, despite of our own passion for some technologies. I don't think that the proper way is fully implementing all in Smalltalk, but "internalizing" the environment in the language as much as we can (in a similar way to Racket people). FileSystem or ZipArchive are a good examples of how to talk with the environment while being inside Pharo making the OS invisible for the user and with a smoother experience. "Internalizing" the environment in the language is the key to keep community and technologies diverse, while keeping the fluid experience of live coding in Pharo. Cheers, Offray
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.
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 <sven@stfx.eu <mailto:sven@stfx.eu>> wrote:
> On 14 Jan 2017, at 12:58, Dimitris Chloupis <kilon.alios@gmail.com <mailto:kilon.alios@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/5c03481aeda7804317e6d9efbb761...
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.
I would give you many more "+" - if you wish - for your opinion: ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Another point I would like to mention: keep the source code locally or at least have an easy option to hold all source code locally. I've seen so many times, that git or one of the other git repositories are down - that's a very critical point. I would like to have a local repository, where I can import external packages and I work locally only. I also have thought several times that it would be nice to have a SQLite database holding all sources/packages. How much easier life would be with that. Other than that: I prefer my simple server directory holding monticello packages - in the Gemstone/S area. But I have to admit, that all the source code management stuff I've seen since ENVY in the Smalltalk community are pretty poor stuff - and even considering integrating git is not a step forward in terms of technical improvements, but only in terms of marketing and mainstream technology. Marten Am 14.01.2017 um 18:44 schrieb werner kassens:
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
-- Marten Feldtmann
Am 15.01.2017 um 10:29 schrieb "itlists@schrievkrom.de" <itlists@schrievkrom.de>:
I would give you many more "+" - if you wish - for your opinion:
++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Another point I would like to mention: keep the source code locally or at least have an easy option to hold all source code locally.
I've seen so many times, that git or one of the other git repositories are down - that's a very critical point.
But....that's always the case with git. You have always all the code plus history locally. Plus you can commit while being offline. Which is exactly one point where git excels. Even envy cannot do that if I understood it correctly.
I would like to have a local repository, where I can import external packages and I work locally only.
You can do that with metacello.
I also have thought several times that it would be nice to have a SQLite database holding all sources/packages. How much easier life would be with that.
I cannot see how using an in-memory sql database can make your life easier. To do what? Norbert
Other than that: I prefer my simple server directory holding monticello packages - in the Gemstone/S area.
But I have to admit, that all the source code management stuff I've seen since ENVY in the Smalltalk community are pretty poor stuff - and even considering integrating git is not a step forward in terms of technical improvements, but only in terms of marketing and mainstream technology.
Marten
Am 14.01.2017 um 18:44 schrieb werner kassens: 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
-- Marten Feldtmann
I find these endless git vs monticello discussions confusing and pointless. Maybe we can hang Q&A list somewhere on pharo website to point to? Because git is getting increased traction in Pharo, so the same questions and endless discussions will popup over and over again. 1. Some people here are acting like STHub and Monticello is going away tomorrow. I don't see how that can happen unless Pharo decides to fundamentally redo its object model. (STHub may die to free some resources, but I don't think that's a foreseeable future plan.) 2. Git is not "new", or "cool", or "bandwagon" technology; it has been here for a decade and more than proven that its value (in fact git is older than Pharo ;)). 3. If you consider the nomenclature confusing because you don't understand or use some concepts, that's fine. That's what tools are for (e.g. I don't use `git add` with Pharo, because I can pick what changes I want with Komitter ( https://www.peteruhnak.com/blog/2016/08/12/fine-grained-committing-and-exten... ) similarly Iceberg should be capable of this too (I am on Pharo 5 so iirc)). 4. Some comparisons between online git managers (github/bitbucket/...) and sthub just show that people don't understand e.g. "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)" The correct version for monticello is (from what I've experienced): I download a program, add something locally, send mail to maintainer, wait, get permission. Now I have complete control over someone else's repository. I release a new version but make a mistake in configuration; now every downstream project is broken and CI informs me only afterwards). If said person doesn't want to give me full access, I have to fileout my changes (or copy paste them), send them by email, wait more. I don't find that a good workflow. If you are working on your own project and want to ignore many things git has to offer (which I do regularly for many projects where it makes sense), then you can have literally the same "one click" with very little work (that can be part of Iceberg/GitFileTree for anyone else to use). You click commit in pharo; now it's on github (or wherever). My views are certainly biased as I've been using git for long time before I came to Monticello, which I still find very limiting. If I am needlessly unfair towards monticello then please correct me --- which is also part of my point; this knowledge shouldn't be hidden in mailing lists (as they are usually disorganized by nature), but in some easily discoverable and structured form (which I guess also loops this discussion back into the original Google visibility topic ;)). Peter On Sun, Jan 15, 2017 at 01:12:37PM +0100, Norbert Hartl wrote:
Am 15.01.2017 um 10:29 schrieb "itlists@schrievkrom.de" <itlists@schrievkrom.de>:
I would give you many more "+" - if you wish - for your opinion:
++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Another point I would like to mention: keep the source code locally or at least have an easy option to hold all source code locally.
I've seen so many times, that git or one of the other git repositories are down - that's a very critical point.
But....that's always the case with git. You have always all the code plus history locally. Plus you can commit while being offline. Which is exactly one point where git excels. Even envy cannot do that if I understood it correctly.
I would like to have a local repository, where I can import external packages and I work locally only.
You can do that with metacello.
I also have thought several times that it would be nice to have a SQLite database holding all sources/packages. How much easier life would be with that.
I cannot see how using an in-memory sql database can make your life easier. To do what?
Norbert
Other than that: I prefer my simple server directory holding monticello packages - in the Gemstone/S area.
But I have to admit, that all the source code management stuff I've seen since ENVY in the Smalltalk community are pretty poor stuff - and even considering integrating git is not a step forward in terms of technical improvements, but only in terms of marketing and mainstream technology.
Marten
Am 14.01.2017 um 18:44 schrieb werner kassens: 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
-- Marten Feldtmann
For those that lost track of the purpose of this thread let me provide a summary The discussion started from the Google Visibility where Sven asked me why I find the Pharo VCS and Monticello a very problematic implementation I decided to reply creating a separate thread in order to not hijack the other thread I did reply with precise details what I do not like and what I consider bad design for both Pharo VCS and Monticello I decided not to further the debate because it was clear that Sven agreed with my remarks its just he did not find them as a show stopper like I do. It was never my intention to debate personal opinion only facts. I have no regrets that I started this discussion, it was a discussion I wanted to start ages ago and at the time I did not feel I was experienced enough to pass a judgement on the Pharo VCS. But I was perplexed for some time why I found and still find Pharo VCS as a deeply flawed system with many problems that have been annoying me since the first day I started using Pharo while there seem to not be any serious complaint from the community. I think now its clear that this happens because: a) Some people indeed find Pharo VCS easier to use and have little interest for the advanced features of Git and Github b) Other people do not like Git because they have not invested the time to learn it and have a very distorted idea of what Git is and how it actually works or how non Pharo coders actually use it (for example the claim that Git is not good for local repos while this is exactly the primary goal of the existence of Git and where it truly shines) c) For some strange reason people who tried Git or still use it partially appear to not use GUI Git client even though Pharo VCS is clearly a Graphical and not a command line based UI. On the other hand I am glad people love Pharo so much and appreciate even more things about it than I do. On a final note I did not make this thread to complain or bash Pharo VCSs mainly because using Git from Pharo never had be an issue for me and I have nothing to complain about the whole process apart from the fact that I do not like how filetree brakes source code into source code files but that is a minor annoyance. Thank you all for your participation and your opinions its great to see another point of view and keep having fun with Pharo VCSs.
I gave a talk at Smalltalks 2016 entitled: "Dangerous Liaisons: Smalltalk, files, and git"[1] and this thread is a perfect example the dangers I was thinking about:). For "history buffs", here's a link for my talk at STIC 2012 entitled "Practical Git for Smalltalk"[2]. Dale [1] http://fast.org.ar/talks/dangerous-liaisons-smalltalk-files-and-git [2] https://www.youtube.com/watch?v=ZIkoBQphtyM On 1/15/17 8:44 AM, Dimitris Chloupis wrote:
For those that lost track of the purpose of this thread let me provide a summary
The discussion started from the Google Visibility where Sven asked me why I find the Pharo VCS and Monticello a very problematic implementation
I decided to reply creating a separate thread in order to not hijack the other thread
I did reply with precise details what I do not like and what I consider bad design for both Pharo VCS and Monticello
I decided not to further the debate because it was clear that Sven agreed with my remarks its just he did not find them as a show stopper like I do. It was never my intention to debate personal opinion only facts.
I have no regrets that I started this discussion, it was a discussion I wanted to start ages ago and at the time I did not feel I was experienced enough to pass a judgement on the Pharo VCS.
But I was perplexed for some time why I found and still find Pharo VCS as a deeply flawed system with many problems that have been annoying me since the first day I started using Pharo while there seem to not be any serious complaint from the community.
I think now its clear that this happens because:
a) Some people indeed find Pharo VCS easier to use and have little interest for the advanced features of Git and Github
b) Other people do not like Git because they have not invested the time to learn it and have a very distorted idea of what Git is and how it actually works or how non Pharo coders actually use it (for example the claim that Git is not good for local repos while this is exactly the primary goal of the existence of Git and where it truly shines)
c) For some strange reason people who tried Git or still use it partially appear to not use GUI Git client even though Pharo VCS is clearly a Graphical and not a command line based UI.
On the other hand I am glad people love Pharo so much and appreciate even more things about it than I do.
On a final note I did not make this thread to complain or bash Pharo VCSs mainly because using Git from Pharo never had be an issue for me and I have nothing to complain about the whole process apart from the fact that I do not like how filetree brakes source code into source code files but that is a minor annoyance.
Thank you all for your participation and your opinions its great to see another point of view and keep having fun with Pharo VCSs.
Several things I disagree with [1] 1) "Living in the image" , I think this is a usual smalltalker misconception in that just because you do not see something it means it does not exist. Obviously thats not the case with the Pharo image. The Pharo image is indeed a binary file and self contained enviroment but not user friendly by itself because the Pharo image only stores bytecode, which is hard to read. The actual source code you see inside the image which what we do 99% of the time is coming not from the image but a file called "sources" and yes its a text file and a typical smalltalk source code file. Of course this does not stop there and we have also the changes files, which is also a text file, for recovering lost changes. Even the more modern Epicea , heavily relies on text files and of course then you have other tools like GTPlayground who store the code snippets also as source code files and of course Monticello which uses mcz files which are nothing more than zip files containing standard smalltalk source filex, again text files. And the story does not end there that we live outside the image far more we are willing to admit , there is of course the VM which the image cannot access , hence why we want to move GUI support completely to the image. But also the foundation of the power of Pharo which is the C libraries it has to rely on to do all of the basic stuff, open, close and create files, read , play sounds, display graphic formats , access databases and a ton more are all outside the image and the image is able to communicate with them either via plugins or the UFFI. 2) I would not call a zip file containing text files a binary based VCS.Thats what a mcz is. Because if we do then so is Git since git as well is Zipping the files because like Monticello , it recognises that is a waste of space to upload uncompressed files. We know how valuable online space is cause pretty much anything online nowdays implements its own type of compression. By the way binary files storing byte code is not anything special , its actually the standard , Java has them in the form of .class file and python has them in .pyc where the first time you run code its compiled and stored to this files and then its those files that are executed , source code itself is never executed. It may have been special in the 70s and 80s but definitely not since 90s. What makes the image special however is the storing of the live state and live execution of code.... but even that is not special because modern applications always utilise a form of storing live data and live execution for means of convenience, but we as Pharo offer this outside the box. So yes the pharo image is special but not as special. Actually the real irony here is that the MCZ is image unfriendly because not only it contains text files but unlike Git cannot version control binary files, you can version control a Pharo image with Git but you cannot do it with Pharo VCS. So Git is more Pharo friendly than Pharo itself at least for that purpose. I always found it strange that monticello does not support version control for binary files , especially if you take into consideration how much value we put in the live state and live context of execution. Also Git has LFS which deals with large binary files and solve the problem of accumulation of wasted space via the git commits. Other than that, as always excellent talk, very easy to understand.... and you do not look like grandpa to me :D On Sun, Jan 15, 2017 at 10:47 PM Dale Henrichs < dale.henrichs@gemtalksystems.com> wrote:
I gave a talk at Smalltalks 2016 entitled: "Dangerous Liaisons: Smalltalk, files, and git"[1] and this thread is a perfect example the dangers I was thinking about:).
For "history buffs", here's a link for my talk at STIC 2012 entitled "Practical Git for Smalltalk"[2].
Dale
[1] http://fast.org.ar/talks/dangerous-liaisons-smalltalk-files-and-git
On Sun, 15 Jan 2017 14:53:31 +0100, Peter Uhnak <i.uhnak@gmail.com> wrote:
I find these endless git vs monticello discussions confusing and pointless.
+ 1 :)
Maybe we can hang Q&A list somewhere on pharo website to point to? Because git is getting increased traction in Pharo, so the same questions and endless discussions will popup over and over again.
1. Some people here are acting like STHub and Monticello is going away tomorrow. I don't see how that can happen unless Pharo decides to fundamentally redo its object model. (STHub may die to free some resources, but I don't think that's a foreseeable future plan.) 2. Git is not "new", or "cool", or "bandwagon" technology; it has been here for a decade and more than proven that its value (in fact git is older than Pharo ;)). 3. If you consider the nomenclature confusing because you don't understand or use some concepts, that's fine. That's what tools are for (e.g. I don't use `git add` with Pharo, because I can pick what changes I want with Komitter ( https://www.peteruhnak.com/blog/2016/08/12/fine-grained-committing-and-exten... ) similarly Iceberg should be capable of this too (I am on Pharo 5 so iirc)). 4. Some comparisons between online git managers (github/bitbucket/...) and sthub just show that people don't understand e.g. "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)"
The correct version for monticello is (from what I've experienced): I download a program, add something locally, send mail to maintainer, wait, get permission. Now I have complete control over someone else's repository. I release a new version but make a mistake in configuration; now every downstream project is broken and CI informs me only afterwards). If said person doesn't want to give me full access, I have to fileout my changes (or copy paste them), send them by email, wait more. I don't find that a good workflow.
If you are working on your own project and want to ignore many things git has to offer (which I do regularly for many projects where it makes sense), then you can have literally the same "one click" with very little work (that can be part of Iceberg/GitFileTree for anyone else to use). You click commit in pharo; now it's on github (or wherever).
My views are certainly biased as I've been using git for long time before I came to Monticello, which I still find very limiting.
If I am needlessly unfair towards monticello then please correct me --- which is also part of my point; this knowledge shouldn't be hidden in mailing lists (as they are usually disorganized by nature), but in some easily discoverable and structured form (which I guess also loops this discussion back into the original Google visibility topic ;)).
Peter
On Sun, Jan 15, 2017 at 01:12:37PM +0100, Norbert Hartl wrote:
Am 15.01.2017 um 10:29 schrieb "itlists@schrievkrom.de" <itlists@schrievkrom.de>:
I would give you many more "+" - if you wish - for your opinion:
++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Another point I would like to mention: keep the source code locally or at least have an easy option to hold all source code locally.
I've seen so many times, that git or one of the other git repositories are down - that's a very critical point.
But....that's always the case with git. You have always all the code plus history locally. Plus you can commit while being offline. Which is exactly one point where git excels. Even envy cannot do that if I understood it correctly.
I would like to have a local repository, where I can import external packages and I work locally only.
You can do that with metacello.
I also have thought several times that it would be nice to have a SQLite database holding all sources/packages. How much easier life would be with that.
I cannot see how using an in-memory sql database can make your life easier. To do what?
Norbert
Other than that: I prefer my simple server directory holding monticello packages - in the Gemstone/S area.
But I have to admit, that all the source code management stuff I've seen since ENVY in the Smalltalk community are pretty poor stuff - and even considering integrating git is not a step forward in terms of technical improvements, but only in terms of marketing and mainstream technology.
Marten
Am 14.01.2017 um 18:44 schrieb werner kassens: 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
-- Marten Feldtmann
-- Using Opera's mail client: http://www.opera.com/mail/
Yep, it is the first situation I face where I need it in 10 years of Smalltalk/Pharo. Otherwise I will refactor super class package, may be I should Le 21/01/2017 à 11:19, stepharong a écrit :
pay attention and to not use it. It is evil to use that in plain domain code.
-- Dr. Geo http://drgeo.eu
Hi Hilaire, I had this once, too. No time to refactor or rethink my subclass structure. Now I am wondering what you guys are meaning by "hooks"? Something like this? A ClassExtension? SuperSuperClass - methodIWantToReach - myExtendedMethod ^self methodIWantToReach SuperClass - methodIWantToReach MyClass - methodIWantToReach ^self myExtendedMethod Thanks Sebastian Am 21.01.2017 um 09:06 schrieb Hilaire:
Yep, it is the first situation I face where I need it in 10 years of Smalltalk/Pharo. Otherwise I will refactor super class package, may be I should
Le 21/01/2017 ï¿Š11:19, stepharong a ï¿Åcrit :
pay attention and to not use it. It is evil to use that in plain domain code.
On 15/01/17 04:29, itlists@schrievkrom.de wrote:
I also have thought several times that it would be nice to have a SQLite database holding all sources/packages. How much easier life would be with that.
That's the core idea of fossil. "GitHub alike in a box" DVCS with tickets, wiki, web server/GUI in 2 MB. Cheers, Offray
On Sun, Jan 15, 2017 at 08:09:28AM -0500, Offray Vladimir Luna Cárdenas wrote:
That's the core idea of fossil. "GitHub alike in a box" DVCS with tickets, wiki, web server/GUI in 2 MB.
Hi Offray, Do you use Fossil with Pharo source code? Just store mcz files as blobs? Pierce
On 16/01/17 07:34, Pierce Ng wrote:
On Sun, Jan 15, 2017 at 08:09:28AM -0500, Offray Vladimir Luna Cárdenas wrote:
That's the core idea of fossil. "GitHub alike in a box" DVCS with tickets, wiki, web server/GUI in 2 MB. Hi Offray,
Do you use Fossil with Pharo source code? Just store mcz files as blobs?
Pierce
Hi Pierce, I don't use Fossil with Pharo source code. I use fossil for all my DVCS needs, including storing Grafoscopio notebooks (which are plain text and diff friendly STON files) and StHub for all my Pharo code needs. What I like about StHub and Fossil is how they become unobtrusive in my work flow, that I almost don't think in them. Hopefully, Iceberg will bring a DVCS neutral way of keeping the same flow. Cheers, Offray
My reasons to like the legacy/mcz style [D]VCS in Pharo: 1) No fuss in saving things when I am starting something 2) Easy to explain to someone new to Pharo 3) Can use any FTP server as a repo (Useful when in a walled garden) 4) Compatible with the package cache, so I can collect mcz's from various projects and put them together and retrieve bits and pieces 5) Some compatibility with Squeak and other Smalltalk, which doesn't hurt 6) Merge tool kind of works 7) Easy to understand format for an mcz, so just get the .st source in it, and do some find/replace to align class names etc when in need 8) If one wants to actually understand the thing, it is all in source code format (educative) Git is better for a number of cases, yes, but why should we only have one thing? Fossil is also great and I'd say taking less of a ton of files as git does (synching my image and the myriad of files in .git/ is really shitty when working in a Dropbox folder, not so with mcz). Git needs regular maintenance, like compaction etc. Sometimes, git breaks. Good luck to recover from that. DVCS ~= backup. Long story short, Git requires more maintenance and freaks out some people. A note for working on Windows, a lot of VM crashes are due to Pharo not finding out the git.exe thing on the path. Check the settings for making this right. Out of the box, it is not. Maybe we should make that clear in a Playground or Help topic so that people do not face this when committing code they worked hard to produce. Phil On Sat, Jan 14, 2017 at 3:14 PM, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
On Sat, Jan 14, 2017 at 3:21 PM Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 14 Jan 2017, at 12:58, Dimitris Chloupis <kilon.alios@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.
I am also amazed at the number of people not using basic git UI tools, like "git gui" and "gitk" + mergetool/difftool settings in the git config (kdiff3, meld, WinMerge, difuse) which make the work of merging so much easier (e.g. "git difftool" or "git mergetool" on the CLI when one encounters issues during a merge or rebase). "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." Err, as a "modern development team member", because as a lone coder trying to do all of this will just spend more time in messing with tooling than by creating the solution. I see that in a lof of shops where docker-compose or git flow is discussed much more than the business logic :-( Phil On Sat, Jan 14, 2017 at 3:14 PM, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
On Sat, Jan 14, 2017 at 3:21 PM Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 14 Jan 2017, at 12:58, Dimitris Chloupis <kilon.alios@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.
Hi, On 14/01/17 06:58, Dimitris Chloupis wrote: [...]
I also never said "Do not use Pharo VCS" , if that is what rocks your boat, but to actual claim that Pharo VCS is more reliable, easier to use and more powerful would require a huge leap of faith because from the very first experience it pretty crystal clear that is not.
And there is not just Git, there are plenty of other VCS out there that are just light years ahead, some probably better than Git.
[...] In our case, with field work with not programmers and newbies, I can tell there is no leap of faith at all. We have been using external DVCs and internal ones. The workflow with the later is simpler, they don't see anything about reliability or difficult. Just update and commit (fossil is similar in someway). Maybe is the small scale of the project or the local community, but in this context, git has been really obtrusive, while StHub for code and fossil for files are not. Cheers, Offray
fair enough, its a free world :) On Sat, Jan 14, 2017 at 4:58 PM Offray Vladimir Luna Cárdenas < offray.luna@mutabit.com> wrote:
Hi,
On 14/01/17 06:58, Dimitris Chloupis wrote:
[...]
I also never said "Do not use Pharo VCS" , if that is what rocks your boat, but to actual claim that Pharo VCS is more reliable, easier to use and more powerful would require a huge leap of faith because from the very first experience it pretty crystal clear that is not.
And there is not just Git, there are plenty of other VCS out there that are just light years ahead, some probably better than Git.
[...]
In our case, with field work with not programmers and newbies, I can tell there is no leap of faith at all. We have been using external DVCs and internal ones. The workflow with the later is simpler, they don't see anything about reliability or difficult. Just update and commit (fossil is similar in someway). Maybe is the small scale of the project or the local community, but in this context, git has been really obtrusive, while StHub for code and fossil for files are not.
Cheers,
Offray
My point exactly. Currently working with a team of testers, they are very happy with mcz indeed. And have no clue of git. Phil On Sat, Jan 14, 2017 at 3:57 PM, Offray Vladimir Luna Cárdenas < offray.luna@mutabit.com> wrote:
Hi,
On 14/01/17 06:58, Dimitris Chloupis wrote:
[...]
I also never said "Do not use Pharo VCS" , if that is what rocks your boat, but to actual claim that Pharo VCS is more reliable, easier to use and more powerful would require a huge leap of faith because from the very first experience it pretty crystal clear that is not.
And there is not just Git, there are plenty of other VCS out there that are just light years ahead, some probably better than Git.
[...]
In our case, with field work with not programmers and newbies, I can tell there is no leap of faith at all. We have been using external DVCs and internal ones. The workflow with the later is simpler, they don't see anything about reliability or difficult. Just update and commit (fossil is similar in someway). Maybe is the small scale of the project or the local community, but in this context, git has been really obtrusive, while StHub for code and fossil for files are not.
Cheers,
Offray
On Sat, 14 Jan 2017 10:09:02 +0100, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 14 Jan 2017, at 00:48, Offray Vladimir Luna Cárdenas <offray.luna@mutabit.com> wrote:
On STHub, fortunately is live enough to let some of us being productive without the noise of git in front.
So true.
Let's stop bashing StHub: it works fine for 1000s of projects. I know we are building something new and I am all for it, but as long as it is not as user friendly as Monticello (all operations clean and simple in Pharo, reliably) we are not there yet.
The point is: we all know how to use git, but most Pharo developers don't want to deal with file based Pharo code, at all, ever.
+ 10000 And so far we deliver and I would add that I appreciate particularly when I see code commits for improvements instead of just rants.
Sven
-- Using Opera's mail client: http://www.opera.com/mail/
participants (18)
-
Dale Henrichs -
Dimitris Chloupis -
Esteban Lorenzano -
Hilaire -
itlists＠schrievkrom.de -
Joachim Tuchel -
jtuchel＠objektfabrik.de
-
Norbert Hartl -
Offray Vladimir Luna Cárdenas -
Peter Uhnak -
phil＠highoctane.be -
Pierce Ng -
Sean P. DeNigris -
Sebastian Heidbrink -
Siemen Baader -
stepharong -
Sven Van Caekenberghe -
werner kassens