Pharo runs in a VM that's compiled to C and runs as a stand-alone native application on Linux, Mac, Windows. You can also build from source but most people don't and there are some rough edges. There are plenty of libraries and mechanisms for connecting to the rest of the world e.g. subprocesses, sockets, FFI, and libraries built on those.

My favourite computer science paper of all time is about how they develop this virtual machine. https://news.ycombinator.com/item?id=12577087

For deployment, you can run it headless.

You can also deploy as Javascript for Node/Browsers via a tool called PharoJS (http://pharojs.org - full disclosure, I'm one of the principals of PharoJS), but it's a work in progress (with a Slack workspace to support it).

GNU Smalltalk can deploy to a standard executable, so you could do most development in Pharo, and then switch to GNU Smalltalk, but you'd lose the fabulous IDE.

Traditionally Pharo could only create standalone applications, but the minheadless builds are making good progress on stripping the windowing code to facilitate it being embeddable.

A platform specific VM runs on Windows, Linux, OSX. All those VMs run a single application binary.

Does it compile to other platforms? Binary code, compile to C, to LLVM? Does it compile to other VMs like Java and it is compatible with javascript engines? For me this is a basic aspect of a language.

Likely the best bits of this environment will be cherry-picked into future Pharo releases, but meanwhile it is available here at https://gtoolkit.com/ and I for one am building an application on it.

In fact, Pharo pretty much can do everything you asked for. It is just amazing to learn a lot of CS concepts. Just so know, Pharo is a great tool to teach. I am a student and this is how I came across Pharo about a few years back.

And you can build both Business applications (http://pharo.org/Companies) or personal applications. Take a look at the catalogue here http://catalog.pharo.org/ and http://smalltalkhub.com/list. You can do almost everything in Pharo. Imagination is the limit to what you can do in Pharo.

And also there is a good list of use cases at http://pharo.org/success.

HTH

The essential problem is that Smalltalk does OOP "right" and what one sees called OOP in the broader community generally does not have that same ideological purity. In addition Smalltalks are a deeply different vision of programming. I don't think I've ever shown a programmer a Smalltalk and had them go "Oh yeah this all makes sense." I have to preface it...

"This is a different vision of programming than you are used to, go ahead and run the executable."

"Um, it opened a desktop?"

"Yeah. So this is the program you are writing."

"What is?"

"This blank canvas."

"Oh, this is a text editor?"

"No, like, the program is running live right now."

"Well can I shut it down and edit it?"

"You edit it while it's still running. Here, go ahead and right click something..."

There's invariably some form of disbelief: surely we wouldn't have made this whole programming thing hard for no reason, so surely this approach to "everything is alive and you are mutating the ecosystem" is impossible for the simple reason that it is not ubiquitous.

It seems that simply mentioning that Pharo is based on Smalltalk would immediately convey a lot of useful information to people who are new to Pharo.

But Pharo's is inspired by Smalltalk, and I myself consider it Smalltalk, but the purpose of the detachment is to not be constrained by having to continue being Smalltalk.

E.g. in Pharo instance variables are first class objects (called "Slots").

and... https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/p...

Squeak and Pharo are great but the font rendering is terrible, I can't stress how bad it looks on hidpi screens. That makes it unusable for me since it gives me headaches. It's a shame too since they have spent a lot of time working on related frameworks (athens?, brick?, bloc?) that alas don't seem to go anywhere (or nobody is in the position to bring everything together). Last I checked they were trying to use a native library from Mozilla (Moz2D which is the backend of Firefox!?!?) to do all rendering, which is highly problematic and disappointing if it ends up being used. The clusterfuck of libraries that they have layered together should clearly point out that this is not the right approach.

On macOS, the graphics stack looks like: CoreGraphics <- Skia <- Moz2D <- Sparta <- Bloc <- Brick

Alan Kay would have a seizure. Aliaksei Syrel: What happened to keeping things simple?

I really hope the graphics issues get resolved since I'm pretty sure they are costing them a lot of users. The regular Pharo devs by virtue of using Pharo every day are (probably) not in the position to realize how a new user coming from environments with great font rendering, UI speed/smoothness, reacts to Pharo. Initial impressions are everything.

Try writing a mode for Emacs, something like Helm or NeoTree or Dired, in Emacs and you'll get pretty much the same experience you'd get from Pharo, although with a lot less visual feedback. Emacs is concerned mainly with text and it's naturally reflected in its APIs, but the fact that you can live-edit any function or advice and see its results change immediately after pressing C-M-x is exactly what Smalltalk/Pharo does.

It's magical, in both versions. Smalltalk was designed for GUI first, so its APIs for manipulating graphical objects are much like Emacs APIs for text manipulation: vast, rather complete, also a bit arcane due to decades of history. There's one thing that Emacs lacks and that would be support for restarting code execution from any place (possibly edited in the meantime) on the call-stack after exception: Pharo's debugger lets you do that, which is a thing worth experiencing at least once as a programmer. :)

My OS and all of its rules, tools and configuration, the UNIX philosophy, the POSIX standard, all of its history and convention: _that_ is my dev environment and it's as LIVE as anything can be.

Not some one-off unicorn IDE - no matter how awesome it is, sorry guys.

My entire toolchain in all of its diversity is one big living ecosystem. That is not, as you eloquently hinted at, a bunch of refined steam engines. It is maglev-level awesomeness. Some pointy-clicky IDE where you can inspect objects with trivial properties is not impressive. It was in the 90s, but now now. Ironically Pharo itself, to me, evokes the admittedly beautiful image of a bunch of refined steam engines. A beautiful thing of the past. Impressive, but obsolete - not unlike France itself.

You have to interact with dozens of systems for even the simplest applications now. Databases, HTTP APIs, knowledge systems, OS'es, all kinds of IoT and machinery, all of which have their own standards, their own philosophies, their own tools, their own way of doing things. None of this would ever work if one tool decides it has the Truth and all other should conform to it. Without the UNIX philosophy none of this would even get off the ground. Because that is wat Pharo is, a tool, _inside_ an already living ecosystem. That is exactly why you get programmers asking, why can't I use my tools, why can't I use the "shell", do this do that.. This tool does not fit the UNIX mindset: it's just another tool, but it pretends to be an entire ecosystem that handles everything. An OS inside an OS. This does not make sense to anyone (but the Smalltalk people apparently). Also, as an aside, that is exactly why emacs sucks (take that HN!!).

For some reason some people think programming is hard because you have to create some classes and struggle with basic syntax. Inspecting trivial object and deciding the value of its sole attribute is "2" or "A" is not what makes our work hard.

And yes, UI _is_ a crutch. Only visual tasks need visual interfaces, think Photoshop. Visual UIs slow you down, that's just a physical fact - how fast is you hand? - and it is totally reasonable for new/incompetent users and/or users that perform visual tasks, but programming is not a visual task. Programmers think in abstractions, in symbols. GUIs have their place to be sure, without autocomplete I would be useless, so there's that, but beyond that, nope, useless crutch for incompetent users. Take that, society.

~Angry Engineer

And this partly explains why the lack of [your favourite editor] bindings isn't so important. You don't typically spend as much time as you're used to typing in code - and make progress faster as a result - counter-intuitive as that may sound. The integration and the debugger are most of the reason why.

I'm incredibly frustrated by environments like Ruby on Rails which pay lip service to the idea of "everything is an object" — but those objects are just a cesspool of hollow non-evolving throwaways that get built up and torn down on every request.

It's the difference between a castle made out of toy blocks and the Buckingham Palace.

1) Much of it is outdated. 2) Much of it supposes significant prior knowledge of Pharo.

Once you start to become familiar with Pharo, neither is much of a problem. You see that the screenshot of Pharo 5 resembles what you see on Pharo 7 in spite of superficial differences. And you picked up enough of the jargon to be able to judge if some documentation is close to your level or not.

For someone who downloads Pharo 7, starts it up, and wonders "what now", most of the existing documentation is confusing. The MOOC was a much better starting point back in October, but with the new system browser in Pharo 7, it's seriously outdated as well.

Here is a link to Python's docs(https://docs.python.org/3/). It's still a little busy, but you can go a long way just by using the Python Tutorial (helpfully subtitled with 'start here') followed by the full Library Reference. A lot of people rave about how great Python is and how popular it's become, but I think one of the unsung heroes of Python's success has been the great documentation.

A (fairly) recent language that appears to have taken a page from Python's documentation success is Google Go. Here's the Go Docs:(https://golang.org/doc/) Take a look at that page. It describes Go, then tells you how to install it, then provides a pretty good tutorial (called a Tour of Go), and then provides a really comprehensive Reference Manual that tells you the various libraries Go ships with, which includes a hyperlink that reveals documentation for each library, and if you explore the linked page and click on a function, that's also a hyperlink that takes you to the actual code for that function so you can read the source code--itself is written in Go. Basically, it's easy to see how Go works, find out what libraries it includes, read good docs for each library, and even explore the library's implementation.

Continuing my argument, I would propose that many of the widely adopted languages of today aren't just good languages, but also benefitted from really good documentation. K&R is still famous, even though the last edition came out in 1989. Here's an interesting question: does C become such a big hit without the fantastic books it had? In the pre-WorldWideWeb universe in which C came to fruition, great books were critical. I would argue no. I believe it's documentation was a critical element of its success.

I think Perl has a similar story. Yes, it was powerful and useful and that was a big feather in its cap, but it also had amazing documentation in the form of books(Camel Book, Llama Book, O'Reilly Perl books in general) and man pages. It's easy to forget--and some don't even know about--the amazing man pages that Perl enjoyed. Here's a hyperlink to Perl's Man Pages table of contents: (http://perldoc.perl.org/perl.html) They are awesome! For example, check out the Perl regex tutorial man page: (http://perldoc.perl.org/perlretut.html) To this day, that's still probably the best explanation of regexes out there. And if that's too much, you can read Perl's quick and dirty regexes man page instead:(http://perldoc.perl.org/perlrequick.html) There's man pages for so much in Perl it's ridiculous.

(Rough waters ahead...)

Now back to your first question about Pharo's current docs. Here was my experience...

I checked out the links you posted. After a few clicks, I got a page with a bunch of pictures that looked like books. I'm wasn't sure what book I should pick, but "Pharo By Example," seemed promising. I clicked on it and discovered it's a PDF--not the preferred format for the web--that tells me the current version of Pharo is still Pharo 5. So I'm already worried because the book is out of date.

OK, I move forward to page 16 before I get to hello world. That's not too bad for a book, but slower than lots of web based tutorials, which is the real competition for "Pharo By Example" since I'm reading it on the web. Page after page then scroll by about Pharo the IDE, but not Pharo the language, which is what I'm really trying to learn about. Finally, on page 28, the book says we get to learn how to define a method, which is apparently how we do anything in Pharo, but then we crash to a stop and write a test first! Then we move forward again until we, at last, get our second piece of code: shout ^ self asUppercase,'!'

That extremely short method doesn't arrive until page 31.

Next we move to Chapter 3 and make a GUI game called LightsOut, which sounds cool, but it's like drinking from a fire hose because none of the syntax or libraries have been explained yet. (Note: At this point, I don't feel like I could run with this example to make games of my own.) If you survive Chapter 3, which is doubtful, and make it to Chapter 4 on page 59, the book finally explains Smalltalk syntax, though even this seems a bit jumbled since the real discussion of message syntax, which is at the core of Smalltalk syntax, is pushed back to Chapter 5 for some reason. Control structures are discussed in Chapter 4 instead. To put that into perspective, there's a mention of blocks serving as lexical closures in Chapter 4 before we really find out how basic messages work in Chapter 5.

By the end of Chapter 6, we've covered the Smalltalk object model and I still have no idea how to actually make a program! At least, I don't think I do.

To put it bluntly, "Pharo By Example" isn't a good programming book. Yes, I recognize it's a labor of love. Yes, I recognize that it's being given away for free. Yes, it took time to write. That's all noble. But it doesn't change the basic, ugly fact: "Pharo By Example" fails to get the job done.

At this point, I'm not at all confident that I will be able to program in Smalltalk after reading this book. More importantly, the book hasn't provided any real reason to become a Smalltalk programmer. It all looks a lot like IDE customization and tools for a language that doesn't seem to run anywhere except in the IDE itself. As an emacs user, I've already got one of those... :)

Seriously, I think some real thought needs to be put into explaining (1) why anyone would benefit from Smalltalk instead of more mainstream language and (2) how to showcase Smalltalk's strengths without getting lost in the weeds of the IDE.

Here's the curriculum that I suggest: (1) tell us how to download, install, and run Pharo (2) demonstrate how to build a few old school IO games--HiLO, Hammurapi, Trek, etc...--so we see how you can do IO. Along the way, introduce Pharo's syntax (3) give a full, long-winded, boring as hell discussion combining and improving upon Chapters 4-6 where you admit up front that it's going to be boring as hell and then (4) go back to saving stuff to Github and distributing the software. (5) explore the various parts of the IDE in independent chapters while providing real examples of how those features make our lives better. (6) go back and provide an entire section of webpages explaining, in great detail, the Morphic stuff that just gets a passing glance in the book for that LightsOut game. It really looks like there's something there, but who knows. That little chapter on Morphic in the back of the book doesn't remotely cut it. (7) provide separate chapters on important libraries? that Pharo comes bundled with--the kind of libraries that all modern languages take for granted and expect. (8) provide some real-world, well-commented, Pharo programs for us to dissect so we can see what they look like. For most languages, I can just download a few open source projects and read code until I'm sick of it. Does that even exist for Pharo?

Let me say again that I honestly think Pharo looks amazing. I really want to know how to make something in it, but I'm not sure I ever will because the amount of effort I'm describing is huge. I hope it happens though.

Finally, I recognize that my feedback was critical. I sincerely hope that you take it as constructive criticism rather than as an attempt to insult. The last thing I'm trying to do is insult anyone.

But, about the GUI, I was thinking about Morphic. It's basically a GUI designer on its own: you can create widgets by instantiating their objects in Playground. It doesn't matter what widget it is: you can create a button or a list item or a textarea on their own. You can then edit them with halo actions or in the inspector until they look like you want, then add them to container widgets, then finally put them in a window. It's bottom-up programming for GUIs! You need to manually track the changes you make via inspector (ie. to copy them to playground), but if you do, you can copy the whole playground into a method and done, you've just designed a GUI app! You later replace some Widgets with their subclasses written by you to handle events and you're done.