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@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