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.
For Common Lisp there are/were many integrated IDEs: Macintosh Common Lisp, Allegro CL, LispWorks, Clozure CL on the Mac, Corman Lisp on Windows upto McCLIM for several CL implementations. A general difference to Pharo is usually that these CL IDEs use mostly native user interfaces. Pharo comes with its own user interface, graphics, window system, display code, event handling, ... Example: Pharo windows on a Mac are not Mac windows. Clozure CL windows on the Mac are Cocoa windows. Similar: most CL systems use native code.
The real commercial Smalltalk machines were underpowered compared to some of the Lisp Machines - for example those from Symbolics - but those were also quite a bit more expensive. It was possible to spend more than $100k for a Symbolics Lisp Machine with accelerated color graphics and HDTV in/out.
The main difference of Pharo with integrated Lisp environments:
1) Pharo uses portable system independent images. Most Lisp systems uses system (OS / architecture) specific images, since code is natively compiled.
2) Pharo code is not native AOT compiled, IIRC. Common Lisp is either source interpreted or AOT compiled - some are even AOT compiled only - with incremental AOT runtime compiler.
3) Pharo uses its own user interface & gui system. Most Common Lisp systems use a native backend for their GUI. Recent exception is Mezzano, which a CL on the metal, which comes with its own GUI.
4) Pharo/Smalltalk usually manages and tracks source code for the user. Most CL IDEs use files and the user works with files and systems of files. CL then more or less tracks the code in these files.
5) Pharo offers to save state in an image between sessions - Lisp systems use that mostly on demand and less as a session state mechanism. LispWorks has some support for sessions.
Quantel Harry was the competition.
Link below, is for the 1981 Quantel Paintbox, the existence of which is responsible for the direction of my juvenile mind.
I should love to one day get together with like minded folk and assemble a complete ca. '89 broadcast graphics suite. I'm in advertising (London, independent, founder) and I'm not convinced that I couldn't work out the financial arithmetic favourably. I am persuaded by artist friends of the merit, tempered I expect by the reality of the working interfaces, if they actually used a 80s Quantel - we take instantaneous responsiveness for granted.. Time and place required, but I'm serious enough to have scouted premises and allocated budget.
I digress. Sorry.
I only have read about Pharo in the last couple of weeks, but I am taken by the sophistication of the ambitions and delivery thereof. I say this here, rather thanon a Pharo list, because I am unsure of what skills and specialities are required, but I have a professional itch to scratch, which is estimating the work of supporting a new language to the fullest extent possible, in Visual Studio. If this could be accomplished in under half a man year for a senior developer, I really want to know. (result to be released to community, purpose of exercise purely personal curiosity about what consequent effect is possible)
The Symbolics Graphics System was more about 3d modeling and animation for TV and games. Paint was also provided - but also in combination with animation.
A very early brochure: http://lispm.de/symbolics-3/symbolics-3.html
A later one in German: http://lispm.de/symbolics-2/symbolics-2.html
You can, with a bit of effort, get OpenGenera running on a Linux VM and display on a modern X server. There are a few patches needed due to recent X server changes, or just run an Ubuntu from a dozen years ago on metal.
The trouble is that what you are dealing with is a graphical interactive programming environment. Sure, you can run it from the command line like /bin/perl, but to understand what you are dealing with you have to open it up and try it on its own terms.
If you aren't interested in a novel immersive programming environment then you can safely ignore Pharo too.
I was curious and so downloaded and ran the default image, and I'm beyond captivated by it, but I have to agree that neither the link nor the homepage do a good job of enticing me to do so, or even hinting and what can I expect.
If I didn't feel like setting up and checking out random projects I stumble upon, I would have never even seen what Pharo is about, given the abundance of marginally different programming languages that pop up on HN.
So yeah, I also think Pharo's best "Hello, World" is just opening it and trying out stuff, but maybe it should try to sell itself, at least a little, for the uninitiated?
Guessing this is a hard problem. People have been working on marketing Smalltalk for almost 50 years now. If there were an easy solution I reckon they'd have found it by now :)
Maybe lots of little gifs?
I was just looking for a basic examples to get some sense what Pharo is about and what the look and feel are. Without downloading and installing it, I wasn't aware that there is a pretty nice interactive tutorial built in.
Maybe convey better how Pharo is distinct from other languages/environments and how to get going?
Pharo is indeed very easy to get started, but the website makes it appear harder than it actually is.
Pharo might be the first project I've seen whose actual usability an user-friendliness is behind that of their presentation :)
The books are all free in PDF form and the lead developer also has another website somewhere where he hosts old Smalltalk textbooks which are largely still relevant.
They certainly could work on conveying this better, but it is open source and likely not a high priority.
For me it was just the initial perception I got. E.g. I only realized that the books were free after you told me. And yes, this is due to me evidently being too lazy doing an additional click. I don't mind paying for books, but not as a first step.
I did download and tried Pharo because I was intrigued by it from another person, if I just were to land on the website from some random link, I likely wouldn't have.
I think there could be some small changes in wording and presentation that would get a long way for people without any prior knowledge of the language. For example if you compare it to Rust (just content, not design wise)
Then try these one-liners in the Playground... https://medium.com/concerning-pharo/elegant-pharo-code-bb590....
Then (and I know its a video) but maybe serverless PharoLambda would interest you... https://www.youtube.com/watch?v=YUbd0-FX6pI
The question is not about a Pharo commandline that exists as part of the Pharo GUI.
The question is about an OS commandline like "GNOME Terminal" with stdio.
— How to run a Smalltalk source code file as a script
— How to use stdio, How to use file handles
— How to load Smalltalk source code from files, save, deploy , and invoke on remote machines
Until `virtualized` has seen that basic stuff can be done, why should they care?
A Smalltalk implementation.
> So starting from those kinds of questions is missing the point…
The questions `virtualized` asked are simple and clear.
Telling `virtualized` that they are missing the point — instead of answering their questions — makes the community seem arrogant.
However, virtualized stated that they gave up after five minutes because they couldn't find a hello world example similar to programming languages they're presumably familiar with, because they didn't want to watch a video or read a book. So explaining that the Smalltalk environment is different, and thus it doesn't make a lot of sense for Pharo's website to advertise with a command line example, is appropriate, since that implementation is GUI-based.
It would be akin to complaining about RStudio's site because someone couldn't quickly find how to run a hello world R script from the command line, when RStudio is about the IDE.
Pharo's website does attempt to "advertise with a command line example" — and then fails to show that the example works.
I kind of like these systems because they remind me of when computers were weird and different and had legitimate tradeoffs. People’s expectations of computers were still rooted in a physical model of interacting with the world. Computers were still very much trying to prove that they were relevant to the “real world.”
COMMAND LINE:
/opt/src/vw8.3pul/bin/visual nbody.vw_run.im -nogui -evaluate "BenchmarksGame program" -a 50000000
PROGRAM OUTPUT:
-0.169075164
-0.169059907
https://i.imgur.com/JwgJ66z.png
You create a new image and then start piecing things together from there. GNU Smalltalk is probably what you want if you want to stick to the CLI. That said, it's not exactly a representative example when you want the same program that prints to stdout or something.
I'm curious to know about this aspect of it because my first step after the hello world is usually to figure out how to host the thing.
Edit: this would be more useful: https://stackoverflow.com/a/17259369
That said, Smalltalk isn't something you use from the commandline typically, or only during deployment or for applying external automation. The GUI environment is fairly key.
The website front page does not show a Pharo program being invoked from the OS command-line and using stdio.
""" $ curl https://get.pharo.org | bash $ ./pharo Pharo.image eval "42 factorial" """
— nobody hit the Enter key?
— the program does nothing?
— the program does something but there was no output?
— there was output but not to stdout?
etc etc
$ curl https://get.pharo.org | bash
$ ./pharo Pharo.image eval "42 factorial"How many would be able to say that `Hello, world` was correct?
You can load and run a smalltalk source file, at the OS command-line, something like —
./pharo Pharo.image st helloworld.st
./pharo helloworld.image
It's just moving files (VM + bytecode image) so — rsync, ssh
iirc something like —
FileStream stdout nextPutAll: 'Hello, world'; cr.also a hello world will never ever give you any idea about smalltalk/pharo.
don't be impatient, this is a system worth playing with, it's quite ~amazing.
I finally found out that the magic invocation was to open up a window by clicking on the background, and navigating to Tools -> Playground, and running `Profstef go.` But they certainly didn't make it easy.
[0] https://ci.inria.fr/pharo-contribution/job/UpdatedPharoByExa...
Run PharoLauncher and Load a Pharo image instance.
Once the Pharo Desktop IDE appears type CTRL+O+T to open Transcript - the system log console abnd type CTRL+O+W to open playground - Playground is a window into which you can type. It can be used for any purpose, but is most often used for typing Pharo expressions and equickly executing them.
(There are windows /icon menu entries for these as well)
In playground window type:
Transcript show: 'Hello World'
You should now see Hello World appear in the transcript window.
What you just did was send the Transcript objects show method the message 'Hello World'
Lets do a slightly more complex Cut and paste the following code into the Playground window and click the play button. The first part installs the Roassal visualization framework. It only needs to be run once. The second part uses ROassal's Mondrian API which offers facilities to describe and render graphs. Mondrian allows mapping of metric values and properties into visual dimensions, such as shape and colors. Cut and paste the second piece of code into playground and hit play doit icon to evaluate. In the view panel you should see a simple tree class browser of the installed classes in the Pharo image with size of class coloured and scaled to represent number of source code lines in each class. Note lines in speach marks are comments.
"-------------------------------------"
"install Roassal visualization engine"
"-------------------------------------"
Gofer it
smalltalkhubUser: 'ObjectProfile' project: 'Roassal2';
loadStable.
"- Make a Simple interactiver Class Tree Browser -"
"---------------------------------------------------"
myBrowser := RTMondrian new.
myBrowser nodes: Collection withAllSubclasses.
myBrowser edges connectFrom: #superclass.
myBrowser normalizer
normalizeSize: #numberOfMethods;
normalizeColor: #numberOfLinesOfCode.
myBrowser
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.
One of the peculiarity of Pharo (and Smalltalk) is that when you shutdown the system, you can persist the whole system on disk (called "the image"). Next time you open it, you start exactly where you left.
All the development tools are mixed with your code. There is no differences between the coding time and runtime (i.e., you code at runtime). If you are familiar with IRB in Ruby, imagine a GUI running in IRB.
This means that it is hard to see the limit between your code and Pharo's code. Pharo 7 seems to bring a bootstrap process where you can build images from scratch. This is an interesting evolution that will vastly improve the development/reproducability/deployment story.
Please don't complain about downvotes, especially not within the first 23 minutes. It's common to receive one random downvote and a couple more piling on, but given a few hours a decent comment will be back in the black.
As far as I understand it: it doesn't necessarily compile in that sense. You are constructing an 'image', which is basically a living environment that your program runs in, and maybe it corresponds somewhat to a VM. But you're not really treating the code that the VM runs as separate to the VM itself.
In some sense I think you might map it to something like a Lisp machine, where you can interact with a running program and its state through a REPL.
Someone more knowledgeable might be able to elaborate on that (or correct the misunderstandings), but it felt worth offering something other than a straight up dismissal of your question.
This is indeed similar to Common Lisp and Emacs.
Back to the original question: the VM runs on Windows/Mac/Linux and on some IoT devices. The code is compiled to bytecode which can then be JIT compiled further on some architectures/OSes. The compiler and the whole infrastructure is exposed and available on runtime.
Pharo has classes for easy FFI to C and for bundling native libraries. I don't know if it's possible to call back from C to Pharo, but I assume yes (many libraries require this). There is no FFI or other integration with any other language (at least as a built-in, there are RPC interfaces for some langs as add-on packages).
As for "standalone binaries" - almost, as you need to bundle the VM with the image; there are some helper scripts for bundling and then launching images.
The most obvious use case is GUI programming, there's also old-school Web programming with Seaside, data crunching and visualization with Roassal. Other than these killer-apps, Pharo is just as capable as any other high-level language, although with a much smaller selection of libraries available.
Another difference might be that most image-based Common Lisp implementations don't use portable byte-code. Some are using byte-code engines, but those are usually not portable across operating systems and/or machine architectures.
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.
EDIT: Nope! I was wrong, see comment below. It promises Arduino support but via some firmware with Pharo itself still running on the desktop.
Every time I look at a programming language, and at the HN it is every second day, I think about what kind of problems can it solve, and for what kind of platforms these compile/run their runtimes.. and surprisingly not many programming languages inform properly about the most basic feature, and prefer to go deeper into their.