[Pharo-users] Thanks for Pharo
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
>> 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"  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.
>  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
>> 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
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.
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.
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.
> cheers -ben
More information about the Pharo-users