The best way to thank us, is to contribute. So put your code where your mouth is and give a much needed helping hand. Suggestions and discussions is all good , but nothing beats old hard work ;)

It can be a bug fix, a new library, a new gui tool, documentation, blog posts or just promotion to other coder of the merits of pharo. It does not matter how you will help only that you will do.

As stef says and I will agree very much "Pharo is yours" , its a project that is unique and dares to go against the general practices and patterns of modern coding and define its own path and do things its own way and still boost productivity and be very useful. It looks like a simple toy on the surface but screams "nuclear bomb" in the deep. But in the end it depends on its own community to give the push it needs to keep going forward and the more the better.

On Mon, Oct 19, 2015 at 6:36 PM Offray Vladimir Luna C��rdenas <offray@riseup.net> wrote:
Hi,

Some notes below.

On 19/10/15 08:39, Jimmie Houchin wrote:
>
>
>>>
>>> There truly is no edit, compile, run cycle similar to other
>>> languages, even
>>> dynamically typed languages with REPLs.
>> I view that we do have an edit/compile/run loop, its just really
>> tight loop!
>> I recently had a passing thought we could market Pharo as REPL+.
>
> Here is what I was saying. In Pharo there is not separate tool for
> editing, then a different tool for compiling and running. Yes, there
> are distinct phases of process requiring editing, compiling and
> running in Pharo, But they all exist in a single process.
>
> In Pharo I can have multiple Workspaces/Playgrounds and multiple Code
> Browsers, Inspectors, Debuggers and Testing Tools all open at the same
> time. I can flow from one to another and they all be viewing, editing,
> executing, inspecting the same objects, instances.
>
> Where else can we have multiple editors, compilers, repls, and
> whatever tools, all operating on the same objects and instances?
>
> As wonderful as Jupyter may be, can it have multiple windows with a
> view into the same repl instance? Maybe? I don't know. But now throw
> into that picture your favorite editor or IDE. Can it have multiple
> files open and seamlessly edit the code running in that single repl
> instance? The same instance as is in the Jupyter.
>
> Even if you get all of those tools communicating via sockets or
> whatever to a single Python/Julia/??? instance. It is still a very
> poor comparison to the workflow in any Smalltalk.
>
> Then you get to the end of your workday. There is no save menu to
> persist the state of all of those tools and repl all working together.
>
> In Pharo, just one tool, Pharo. Everything exists inside Pharo.
> Wonderful.
>

Talking about Jupyter/IPython, the portability and moldability of Pharo
is something really empowering and difficult to find anywhere else
(which doesn't diminish the advantages others' huge ecosystem, just we
have different advantages). I wrote about my path from IPytho/Jupyter to
Pharo in my over-publicized but under coded :-P project [1]:

[1]
http://mutabit.com/offray/static/blog/output/posts/grafoscopio-idea-and-initial-progress.html


>
> Absolutely. The already existent, persistent live environment is a
> powerful thing. The fact that we have code in Pharo that is decades
> old and has never been in a state disconnected from a live, running
> environment is amazing. Where else do we find that? What other
> software, programming language has a vision to provide such facility?
> Most everything else is designed to build something which you release
> and run. Release from your edit, build, compile to a run environment.
>
> Smalltalk and therefore Pharo is ontological and not merely a tool to
> build something external to itself. This is a huge difference.
> https://en.wikipedia.org/wiki/Ontology
>
> One of the things I find inspiring in the talks by Richard Hipp about
> SQLite is the level of the quality of the code in SQLite. That its
> file format is stable and guaranteed. That its codebase has complete
> test coverage. Coverage sufficient for its use in avionics systems.
> http://sqlite.org/testing.html
>
> I know Pharo is not going to be used in such a system. But it would be
> interesting if we can have decent coverage on the core or kernel as
> the everything get reduced to a buildable system. Then test coverage
> can more easily be applied on a system which is smaller and
> understandable. I have no concept of how you do the vm.
>

We could think on something like SQLite ubiquity for Pharo, not in the
storage backend, but in the writing frontend (blogs, books, code
snippets/scripts, data visualizations)�� with a portable "pocket
infrastructure" (as I call it). Pharo is an awesome pocket
infrastructure that can be run from a thumbdrive, computer sticker, low
end server and anything between and beyond. And there are new scenarios,
like open/citizen/garage science & research, activism, data journalims
and others which lack of the proper tools for being really open,
empowering and democratic and putting them exclusively on the "cloud"
doesn't help that much. (A related idea on this track is on [2])

[2]
https://www.newschallenge.org/challenge/data/entries/data-kitchen-frictionless-data-moldable-tools-pocket-infrastructures-permanent-workshops-for-community-empowerment/

So which are the places where the empowerment that Pharo/Smalltalk
brings will be ubiquitous? (I always take my custom Pharo with my keys
thumb drive).

Nice to see we can effectively explore/build the future together.

Thanks,

Offray