Google visibility?

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/

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

 

Remember we have to compete with languages like Ruby and Python .

 

 

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 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 Sat, Jan 14, 2017 at 3:21 PM Sven Van Caekenberghe <[hidden email]> wrote:

> On 14 Jan 2017, at 12:58, Dimitris Chloupis <[hidden email]> 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.

Sven Van Caekenberghe-2 wrote

so it is not a good idea for an open source project, as I feared.