[Pharo-users] Thanks for Pharo

Dimitris Chloupis kilon.alios at gmail.com
Mon Oct 19 12:57:54 EDT 2015


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 at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-users_lists.pharo.org/attachments/20151019/16783914/attachment.html>


More information about the Pharo-users mailing list