[Pharo-users] Thanks for Pharo

Jimmie Houchin jlhouchin at gmail.com
Mon Oct 19 09:39:36 EDT 2015



On 10/18/2015 11:51 AM, Ben Coman wrote:
> Thanks very much for your thoughts Jimmie.  Day to day, its easy to
> take for granted what we have.
>
> On Sat, Oct 17, 2015 at 6:14 AM, Jimmie Houchin <jlhouchin at gmail.com> wrote:
>> Sometimes conversations revolve around perceived deficiencies in Pharo. What
>> Pharo is missing. Or what Pharo doesn't do as well as my previous language,
>> my favorite language, my other language, etc... These conversations are
>> necessary to understand where Pharo is and to provide understanding on where
>> Pharo needs some work.
>>
>> However, not enough gets said sometimes for all the goodness Pharo already
>> provides and thanks to all of those who have contributed over the years to
>> Smalltalk/Pharo.
>>
>> I know sometimes we get stuck in the minutiae and lose the big picture.
>>
>> I just want to say thanks to all that have contributed to Pharo in big and
>> small way. Thank you.
>>
>> A special thanks to Stef, Marcus and company who have been working hard on
>> this all the way back when it was still Squeak. Who had a vision for a
>> clean, empowering, business ready, vision fulfilling Smalltalk inspired tool
>> we call Pharo. Thanks.
>
> Stef's "Pharo Vision" [1] document was a big part of what drew me to
> Pharo.  Not necessarily what was in it, but more just that there was
> such a vision.
>
> [1] https://gforge.inria.fr/frs/download.php/30434/PharoVision.pdf

Absolutely. This is a very important thing. A vision that moves the 
community and project forward is exceptionally important.

To me  a project without a vision statement or at least a roadmap is 
direction less and quite possible dying. Show me some life before I 
invest my time.

>> And a thanks to Eliot and all who contribute on the VM side of things.
>> Enabling us to have a nicely performing and stable vm to run the Pharo
>> image.
> ...
>> I want to take time to appreciate some things in Pharo that make us
>> appreciate having a tool like Pharo and which distinguishes itself from
>> other languages and environments. I think these things either distinguish
>> themselves either in the relative uniqueness or in quality of their
>> implementation. They are not necessarily distinguishing from other
>> Smalltalks but from other non-Smalltalk languages.
>>
>> Superior persistent live object environment.
>> This is the game changer and affects and enables all other benefits.
>>
>> IDE, debugging and refactoring, all live, all the time.
> The debugger (within a live environment) does it for me.  Its what
> make using Pharo fun.

Exactly. You hit a bug, execution stops and you can start exploring the 
problem where the problem is. With live tools and the executing code 
available and inspectable. No dead stack trace saying go to another tool 
and look at line X and you might find your problem. Or it might be in a 
different file or ...

And if that doesn't do it for you. Execute your program in another tool 
in order to debug and explore the executing code. To many separate, 
isolated and distinct processes and tools.

>> Because of the truly persistent live environment, there is no concept of
>> shutdown, restart. We only know hibernate and resume. This is to use OS
>> terms. For me this is an amazing boost to productivity. I can at any time
>> save my image. Even close my saved image and resume exactly where I stopped.
>> At any time, on any supported  OS, on any machine. Powerful.
>>
>> 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.

> In addition:
>
> The ability for the system (and community culture) to evolve a live
> running system.  This is ideal for applications like control systems
> for industrial plants running 365x24.  For example an alumina refinery
> where kilometers of pipes carry fluids at 800 degree, which would
> solidify in the pipes if there was an 8hr power outage, which could
> essentially close the plant down permanently so you'd have to walk
> away from a billion dollar investment.   Another example might be
> space faring robots.  Pharo is not right now at the point where you
> might trust it for such an extreme purpose, but the potential is
> there.

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.

It would be nice to get to a point some day that certain quality 
standards can be insured to a certain point. Not necessarily to the 
extent that SQLite does. But to a nice level. But SQLite has money, 
supporters, paying for SQLite to have that level of coverage. That also 
makes a big difference.

Thanks for engaging in the conversation.

Jimmie



>
> cheers -ben
>





More information about the Pharo-users mailing list