It's a Smalltalk. It's half language, half environment. The language itself is one of the inspirations for Ruby, and you will find in Pharo a purer expression of much of Ruby. The whole, 'everything is an object' applies, but so does 'everything is message passing,' and in a much more thorough way. The language's syntax is almost reminiscent of LISP in its simplicity (not its actual form, but there is so little of it that you start to feel like you're working directly with the objects, rather than programming them).
The other half is the environment. It's possible to run Pharo code, e.g., from the command line, but if you do all of your Pharo coding and debugging from a traditional editor+terminal combo, you're missing out on most of the reason to use the environment in the first place.
The environment is 'live' while you code. The objects are live, and the environment itself is an object you can interact with. When you add code, your code executes within that very same environment. There is no separate runtime. The runtime and the codetime are the same. Your code simply gets saved as part of a Pharo 'image' you are editing, and this image can be reloaded and resumed from where you left off.
The most common idiom is to program with a "TDD on steroids" approach. You create a skeleton of a few tests, and start it running. The debugger will stop and tell you the object you are sending Message X doesn't respond to that message. So while the debugger has paused the environment, you add the method with the help of the integrated GUI. Smalltalk (the original Smalltalk) pioneered the use of a 'class browser,' which does what it says on the tin. Pharo includes and extends this concept. Once you've added your method (or even, added the class entire), just hit resume and the (incredible) debugger will take you to the next bit that needs fixed. This is a more powerful edit-and-continue that actually works.
Having said that, while I enjoy playing around with the environment and using it to prototype some class hierarchies, I've had a tough time finding a professional use for it. The very qualities that make it mind-expanding to learn and play with, seem to limit its use "in production," so to speak. Who knows, maybe I'm unique, but I couldn't see myself in a hundred years being able to convince my employer to use it.
But it really is an eye-opening experience to learn. Just like learning LISP pushed my personal boundaries although I don't use LISP at work, similarly Pharo has pushed my boundaries in a way that I highly recommend experiencing.
Mostly consider it a programming language and deeply integrated development environment. However its a flavor of Smalltalk which ran as the operating system on mini-computers circa 1980s. Pharo retains some of that influence. For example the whole runtime state of your application can be saved to disk and moved around like you would move a VMWare image.
"Pharo is a mininal, elegant, pure, reflective object language with a goal to deliver a clean, innovative, free and open-source immersive environment." [1]
The other half is the environment. It's possible to run Pharo code, e.g., from the command line, but if you do all of your Pharo coding and debugging from a traditional editor+terminal combo, you're missing out on most of the reason to use the environment in the first place.
The environment is 'live' while you code. The objects are live, and the environment itself is an object you can interact with. When you add code, your code executes within that very same environment. There is no separate runtime. The runtime and the codetime are the same. Your code simply gets saved as part of a Pharo 'image' you are editing, and this image can be reloaded and resumed from where you left off.
The most common idiom is to program with a "TDD on steroids" approach. You create a skeleton of a few tests, and start it running. The debugger will stop and tell you the object you are sending Message X doesn't respond to that message. So while the debugger has paused the environment, you add the method with the help of the integrated GUI. Smalltalk (the original Smalltalk) pioneered the use of a 'class browser,' which does what it says on the tin. Pharo includes and extends this concept. Once you've added your method (or even, added the class entire), just hit resume and the (incredible) debugger will take you to the next bit that needs fixed. This is a more powerful edit-and-continue that actually works.
Having said that, while I enjoy playing around with the environment and using it to prototype some class hierarchies, I've had a tough time finding a professional use for it. The very qualities that make it mind-expanding to learn and play with, seem to limit its use "in production," so to speak. Who knows, maybe I'm unique, but I couldn't see myself in a hundred years being able to convince my employer to use it.
But it really is an eye-opening experience to learn. Just like learning LISP pushed my personal boundaries although I don't use LISP at work, similarly Pharo has pushed my boundaries in a way that I highly recommend experiencing.