[Pharo-users] Thanks for Pharo

phil at highoctane.be phil at highoctane.be
Mon Oct 19 16:06:29 EDT 2015

I like the nuclear bomb image :-)

On Mon, Oct 19, 2015 at 6:57 PM, Dimitris Chloupis <kilon.alios at gmail.com>

> 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/7b36f703/attachment.html>

More information about the Pharo-users mailing list