For those wondering what it's like to program in Pharo or why there aren't a lot of code snippets floating around in Pharo materials: it's because the way you program in Pharo somewhat different than most languages. Pharo is an IDE in the true sense, i.e. while it's technically possible to open up a workspace (text editor) window and write a new class all on one screen this is not how things are done in practice.
Programming in Pharo is usually done either in the class browser or the debugger so that you're only ever seeing the code for one method (called a message in Pharo) at a time. Pharo and other Smalltalk variants tout simplicity of syntax but leave off the fairly complicated class hierarchy and message coupling semantics ergo the necessity for an extremely powerful browser. In the browser, messages for each class are further separated into 'protocols' such as methods for 'accessing' or 'initialization' (these are not part of the Smalltalk syntax, just a convenient layer of organization). At each level in the hierarchy, the Pharo code browser gives you a nice template to edit when you want to make a new package, class, or message. The overall effect is that you're only ever working with a handful of lines at a time and, indeed, Pharo will warn you if it thinks your message is too complex. Doing things this way actually makes everything quite manageable. One of the nice features of being pure OO is that everything is a pure black box so you just need to know that a class exists and take a peek at its interface to use it effectively.
To that end, Pharo actually has an excellent search tool that's not present in other Smalltalk variants like Squeak or Cuis. It does some kind of intelligent voodoo and can find anything from definitions to instantiated objects to senders and receivers of a certain message and so on. You can also open up a playground window to experiment with whatever code in the REPL style. But it's actually a little bit more robust than a traditional REPL because of the pure OO nature of Smalltalk. The thing you get back from evaluation isn't just some text. It's an object with all the associated possibility of reflection and manipulation (which can all be done from a UI, not just from evaluating more code).
One of the things Pharo does better than almost every other language is debugger integration. Pharo is like LISP in the sense that you can start an application, have it encounter an error (or just pause execution at will), drop into the debugger and change some stuff, reify whichever execution stack frame, then resume the program as if nothing ever happened. This is the essence of the other common Pharo workflow: write some partial code and then fill it in incrementally in the debugger until you have a fully functional and bug-free application. In addition, Pharo has its own robust unit testing system called Sunit that, coupled with the debugger workflow, creates a fantastically ergonomic TDD experience.
No matter where you are in the Pharo environment, Smalltalk code gets full treatment (E.G. syntax highlighting, code completion). So what does the syntax look like? Well, it actually has that concatenative elegance of Forth plus a few other constructs. Pretty much everything is a message send. Message sends come in three flavors: unary, binary, and keyword. Constructs like conditionals are also just message sends. In addition, there are first-class lambdas (called blocks in Smalltalk). Here's the canonical factorial program:
"Factorial function"
fac := [ :n | (n = 0)
ifTrue: 1
ifFalse: [ n * (fac value: (n - 1)) ]
].
where " ... " is a comment, ':=' is assignment, '[ ... ]' is a block, ':n' is the block's argument, arithmetic operators are actually binary message sends, things like 'ifTrue:' are keyword message sends (unary message sends are similar but don't have colons or parameters e.g. 'SomeObject new.'), and the statement is terminated with a period. Apparent recursion is fine because Smalltalk uses late binding. Aside from some syntax for strings and class declaration, that's basically it.
Pharo also has a lot of other nice features such as keeping a log of code changes in case of program crash or power outage, an integrated package manager/version control system, and optional git integration. It's all pretty easy to use and overall the system is quite impressive with a high degree of polish and decent performance (comes close to or exceeds node in my experience). However, as others have stated, it's a walled garden. All UI interaction happens within the Pharo environment with no option for native. If you want to break out on UNIX, you have write some kind of server and use sockets or the filesystem (which isn't a huge handicap in the grand scheme of things). On the other hand, application deployment is a little iffy. There's no readily apparent scheme to pare an image down to just what your project uses and then distribute that; users would have to install your package from within their own Pharo environment.