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.
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.
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.”
/opt/src/vw8.3pul/bin/visual nbody.vw_run.im -nogui -evaluate "BenchmarksGame program" -a 50000000
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?
$ 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
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.
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"
smalltalkhubUser: 'ObjectProfile' project: 'Roassal2';
"- Make a Simple interactiver Class Tree Browser -"
myBrowser := RTMondrian new.
myBrowser nodes: Collection withAllSubclasses.
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.
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.
Sounds incredible! Git integration and related code management changes are especially nice, 64-bit by default is great and support for binary packages is also important. New, extensible code browser (Calypso) also sounds impressive, but I'll have to see it in action first.
Pharo is an incredibly productive environment. Fully inspectable everything (on the language level, but also on GUI level - you can inspect all kinds of widgets interactively) and the Debugger where you can define your logic as needed make for incredible programming experience. Plus, it's Smalltalk, which is a beautiful language in its own right.
With this release, it looks like Pharo may finally become more than just a toy. Looking forward to it!
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.
- developing personal projects?
- developing business projects?
- can be deployed to desktop platforms? mobile ? web?
- Has GUI library support?
Without a clear break down of use cases, I am just lost in the cool technology without any way of determining if it fits my needs.
A good example of how to do this well is GameMaker Studio: https://www.yoyogames.com/gamemaker
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.
I'm going to throw this in here:
"Squeak or Pharo for the beginning Smalltalker?"
And a third option that is much leaner and maybe less overwhelming especially if you are interested in actually learning Smalltalk itself to begin with:
Anyways, the dedication of the team is really remarkable. It looks like a really useful learning/teaching tool for OOP. I'll try and hopefully beat my prejudice.
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."
"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.
Microsoft used to market advanced versions of their BASIC -- such as QuickBASIC for DOS -- by having it open several windows on the screen and draw or animate something different in each. A similar program shipped as a demo for Microsoft's AmigaBASIC.
The only thing I can recommend it watching some Alan Kay videos or Pharo demos.
Windows and Linux UI conditioned everyone to think of UI as a crutch for incompetent users, rather than a tool useful in its own right. This cannot be undone in a single reply, no matter how elaborate it will be.
Traditional tools are definitely more polished at the moment, but they are exactly that - traditional, shaped by historic accidents, rather than design. Software development is currently running on a set of highly refined steam engines.
For example, what are the chances that a simulation of a teletype is the best interface for interacting with an operating system? What are the chances that the best conceptual model for a unit of information is manila folder or a phone book ("files", "directories").
Also, IDE came to mean "bloated monolith for editing and compiling code". But it should really mean that application interface is the development tool. Tools that are integrated into OS and applications.
Any sluggishness you experience with Gtoolkit, by the way, is because Bloc is being hosted in Morphic (the current graphics system) temporarily.
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.
So the UNIX philosophy was the only possible way computing could have gone to result in a diverse set of systems that communicate with each other? Is there some sort of CS proof of this claim? Or was it just how history played out?
> 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.
Alan Kay and some others have thought programming would be more productive if it took place at a higher level than manipulating text and files. You might not agree with that, but the reason you have such good tools for text and file manipulation is because the Unix way prevailed. Magnitudes more effort has been poured into making that tooling than alternative approaches.
> 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.
Well, ask someone with a lot of VB or Smalltalk experience how much the environment slows them down in comparison. Because you often hear the opposite.
> 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
I guess debuggers, refactoring and class browsers aren't useful, then.
> Impressive, but obsolete - not unlike France itself.
But still, yeah.
> So the UNIX philosophy was the only possible way computing could have gone to result in a diverse set of systems that communicate with each other?
I don't know and it is not relevant. If you're so inclined you may come up with another paradigm. Anyway, Pharo in particular is not such a paradigm, it's a fancy tool. Fancy, but a tool and it should behave as such and should co-operate, and it doesn't and that makes me very, very, very angry. And upset. And hurt. :-)
> Alan Kay and some others have thought programming would be more productive if it took place at a higher level than manipulating text and files.
I understand, but saying "text manipulation" is quite derogatory. It is _symbol manipulation_, that is what we are doing. The underlying mechanisms of the OS, filesystem and various media are irrelevant. What if I don't work with files, but "symbol maps" or whatever the F* some academic can come up with in his own custom fancy GUI tool. It doesn't change one bit. I still have to manipulate symbols and it still needs to be encoded somewhere. Increases on the fancy-dimension mean decreases on the is-robust-and-useful-in-a-general-way-dimension, not to mention the works-at-all-in-20-years-dimension.
Text files are just low common denominators. They are simple to understand and work well, not only across space, but more importantly, time as well.
> Well, ask someone with a lot of VB or Smalltalk experience how much the environment slows them down in comparison. Because you often hear the opposite.
I know, but that's not the point. I'm not saying Pharo is bad at what it does, being an excellent IDE. It's wonderful. I'm opposed to the ideology of throwing away all UNIX lessons and integrating everything into one God-system. I guess I've upset not only the Smalltalk, but now also the Windows people. Sorry.
> I guess debuggers, refactoring and class browsers aren't useful, then.
These are aids, typically implemented graphically, but not always - Vim has excellent autocomplete, refactoring and class-browsing plugins. Yes, some tasks map excellent to the visual metaphor. Scanning hierarchies and seeing high-level overviews are indeed useful abstractions, but that is not the point. The point is that if you want an excellent debugger, use an excellent debugger. If you want a good refactoring tool, use a good refactoring tool. Don't throw it all in one system and call it a day. That is not the UNIX way and yes, I am saying that is the superior way. In all of its vulgar, plebeian ways, the UNIXes have stood the test of time and I'd seriously reconsider dumping that.
~ Angry, but generally peaceful if slightly anxious and over-caffeinated Engineer
However, today's Pharo has made significant progress with interfacing to "foreign" stuff. The file system has become a first-class citizen of the environment. There is an FFI to work with C libraries. And of course support for network protocols. Source code management is based on Git. It's the GUI that remains in a world (window) of its own, but otherwise Pharo's system integration level is just a notch below languages such as Python or Ruby.
So Pharo/Smalltalk can be orders or magnitude less complex that a full OS and yes is running inside one, but for me that means that it gives you a unified way of dealing with environment/OS complexity (mostly incidental) by providing an interactive, live, supporting place to thing about your prototypes. I made Grafoscopio using Pharo, after trying the Operative System approach and translating symbols to files and dealing with that mismatch and with a plethora of (incidental) complexity (See ). Despite of being a Unix/Linux user since 20+ years and a novice coder at that time, the feeling of empowerment provided by Pharo compared to the tools I was using in Linux before was pretty big.
I'm glad you have decided to test the tool by yourself and I highly recommend reading  for a deeper understanding on how Unix and Pharo/Smalltalk compare to each other and how the last implodes complexity, even when living inside the first one.
Now, I am also using Pharo to do things on Linux and it is easier and faster to get results out of it, especially when I need to fix a failure.
Pharo is not replacing the OS (even if it may feel like it).
One can deal with a running Pharo remotely (either via VNC directly into Pharo or with Pharo7, using Calypso remote connections).
I am with you on the symbolic aspect but still, having an image that one can inspect is great. I was not understanding its value when I started. Now, I do. And I also find it awesome to have a stacktrace saved to disk on a server so that I can reload it into my desktop box and see exactly where things went south, including variables, values etc. Try that with a core dump.
Now, to each its own and I have a personal little project I should actually deliver, namely being able to expose a fuse filesystem from a Pharo image, so that I can use vim and tmux and those things right from a server. There is no technical issue doing this, just damn code it.
The current Pharo is not an OS inside an OS. UnifiedFFI actually makes it easy to bind with C libraries (heck, I wrapped LibStrophe which is full of callbacks, callbacks that are actually written in Pharo, including full debugging on callbacks, see https://docs.google.com/presentation/d/1HTG3GB3xdwlje8wADZPj...) and the more Pharo evolves (been there since Pharo 2.0) the more it delivers on what I need.
With the new boostrapping, one can actually have images with just the bare minimum (no UI, no devtools) so that it can run.
Also there is lowcode, a way to do really fast stuff in Pharo (actually putting C types in there): https://hal.inria.fr/hal-01353884/document
What is also interesting for me in Pharo is that it actually stood the test of time. I am sick of new languages that pop up all the time, where one is relearning the basics with half baked libraries. Pharo core classes are solid, work well and after working in there for a while, it becomes second nature to do quite advanced stuff that one would not even dream to do in, say, Java.
Pharo is indeed a tool and in my toolbox, it is one the best ones so far. Coupled with Unix tools, it is a beast.
I not care if it is getting popular or not. What I care is that it works, that I can influence its course and change what is not pleasing me (try that with other toolchains).
And also that its community actually owns it, not a commercial organization like Oracle, Google, Microsoft...
In that regard, Pharo is pretty much aligned on Linux.
The Pharo community understands the limitations or warts of Pharo, because there are some. But the features are currently delivering a net positive.
And, a little thing that is quite important: I have fun creating and maintaining systems I have done in Pharo.
This really contrasts with other solutions where fighting with accidental complexity takes 50% of the time, if not more.
Anyway, to each its own. I can relate to being angry when engineering. Pharo is lowering the level on my WTF-o-meter, which is actually good.
I share your concerns, actually - the truth is, the code editing part of Pharo is its least compelling feature and just cannot compare to my Emacs setup with years of tweaking behind it - and I tried working outside of Pharo at one point. The main problem with that was the loss of many features of Pharo IDE: autocompletion, go to definition, who calls a method, refactoring support, unit test support, debugger (it's magic, really), eval anything anywhere and more.
In the end, I decided that it's not worth it to insist on using my normal tools and learned to use Pharo as a whole (although text editing still sucks, which can explain why the average length of a method tends to be so low in Smalltalks...)
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.
For 99% of programmers out there, programming IS typing on a keyboard. Clicking around with a mouse is only something that non-expert users (or children, e.g. Scratch users) do, because it is approximately 10x slower to get anything done by laboriously pointing and clicking than by typing. For example, finding the largest file in my home directory through the GUI takes 5 careful targeting operations and 5 clicks, a click-and-drag, and then some scrolling, and then I have to do more dragging to move the window around so I can see what's under it. Using a keyboard I type "ll -S" and I'm done in half a second (and immediately able to issue the next command). You simply can't compete with that.
Even though it isn't the same way you are used to operating, I think it will be necessary to take into account the needs of that audience if you want to bring them on board.
As a thought experiment, what would it take to make the environment comfortably usable with only a keyboard, including discoverability of all the necessary keyboard controls? You could treat it as an accessibility issue; what if the user is unable to use a mouse?
There is the infrastructure for custom key-bindings in place, although last time I checked it was being rewritten; I think that was finished around 6.0.
What it would need, in my opinion, as someone who almost never touches a mouse myself:
- either a tiling window manager or a set of fixed layouts for where windows should appear. I'm not sure how is the placement of new windows currently done, but it's rather dumb.
- something like this: http://oremacs.com/download/ace-window.gif for switching focus between windows. Failing that, the ability to switch focus to the window on the left/right/top/bottom. switching between hordes of ungrouped windows in Ctrl+Tab is a nightmare.
- easily overridable global key bindings. This was rather complicated last time I checked. Also, the key-binding model should be powerful enough to allow for chords (sequences of keys: Ctrl+X, then Ctrl+Y, etc.).
- a mode which would go through all the widgets in the current window and display all available labels (over buttons and menus). Most of the labels contain a name of a function and a keyboard shortcut already.
- there's a Shift+Enter shortcut which opens Spotter: you can type some characters and it will search the image for anything matching, including code, comments, external packages, and global menu items. It would be great if it was also context-sensitive so that you can invoke functions of the currently focused window through it too.
- Emacs/Readline and Vim bindings provided in the base image would be very appreciated.
That would be a good start, I think :) It's a lot of work, though, and there doesn't seem to be a will to pursue this in the community, unfortunately :(
As a Pharo contributor, well, there is indeed some clicking involved but not as much as you may think.
Keybindings are okayish at this point but can use some more love indeed. But this is not related to the core of Pharo but to the tooling that can be improved on some aspects (and this is moving forward actually).
If a user is not able to use a mouse, well, maybe the user can have a CI that integrates all of the code written in Tonel format and pushed to a git repo. Can work, Tonel format is pretty readable and usable from a command line.
There are ways to use Pharo as a "normal" language. But then, what's the point.
I see the new framework for keyboard shortcuts was completed. There are many shortcuts to customize in preferences now. Congrats! :)
Still, the shortcuts by default are totally different than the usual. Is it possible to make for example readline (bash) emulation with the new keyboard shortcuts code? Where would you start if you wanted to do this?
> As a Pharo contributor
I played with 7.0 yesterday, I have a few questions, maybe you'll be able to help me:
- I work on a Linux with high DPI display. I increased the font size of everything to extra large and set scaling factor, which helped, but the cursor is still tiny and almost invisible. I tried reading the code in HandMorph and Cursor, however, the beCursor method which handles displaying of hardwareCursor (I assume) is a primitive. I downloaded the opensmalltalk-vm and after a short fight with it succeeded in running its image. I found primitiveBeCursor method, but it calls C-level function called something like `ioSetCursorSomething` - and I couldn't locate that function. Do you know where it is?
- when you set scaling factor and font size, it's not universally recognized. The menu at the top of screen didn't change its font size, the lists with columns (in preferences, in debugger, etc.) have fixed column-size which truncates most entries (and splitter for changing the width of a column is barely visible), some elements start overlapping (tabs in the browser obscure the row with instance/class side, flat/hier and so on), the windows seem to have hard-coded initial extents which ignore font-size and scaling. To be honest it's barely usable right now for me, to the point that, to play with it, I had to create a dummy Xvnc display and run Pharo there, then run x11vnc on the Pharo window id and finally connect to it via VNC client, scaled the whole thing up. It's a bit nightmarish an experience :) Is there any work towards making it better in progress?
- related to the above, is it possible to set the initial extent of the Pharo window (the top-most, OS-level one, I mean) on the command-line? There's a switch for starting in iconified state or fullscreen, but I didn't find one like `size` or `geometry`.
- What are class "extensions"? Are they simply traits, or is it something new? Is it documented somewhere?
I see lots of great progress on all fronts, but Pharo remains rough around the edges. The discoverability of the details is great, but the bigger picture - an overview of all the toolkits, for example, or a succinct description of architecture - is very hard to piece together. The new package manager interface finally displays a bit of description for each (this wasn't the case for a long time), but many packages have no description. Coupled with package names being rather hermetic this makes for a frustrating experience. I'm a rather persistent kind of guy and so I stuck with Pharo despite all that, but I imagine many other devs wouldn't care to do this, unfortunately.
Extensions are methods installed into classes by other packages.
Out of the emulations I’ve seen, JetBrains one is perhaps the closest to real vim (albeit not without a few weird corners). If Pharo is so flexible and modular, wouldn’t it be quite easy to add official support for vim mode?
// I’m honestly baffled at why people who code for living often do not use vim keybindings for coding, but that’s a separate story
And smalltalk does bring a lot of compelling features, as others here have noted.
(And some emulators are quite good, like evil-mode, which has converted some hard-core vimmers. Which also makes me wonder about implementing the core of emacs in smalltalk, making similar functions available, and extending it with smalltalk instead of elisp.)
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.
That's one of the key benefits: the environment is an object too.
First class IDE knowledge about your objects (Smalltalk pioneered automatic refactorings etc), the ability to modify it as you like, hot code reload, re-startable apps, "live" images to send for debug, etc.
I come from Emacs (20+ years when I first encountered the Smalltalk IDE), and find aspects of code editing irritating sometimes, but the overall value of the IDE more than pays for that irritation.
One of the coolest things is TDD carried to an extreme level. I build my test, and it fails because there's no such method, so I get a debug window and tell it to create the method... then I fill in the contents and click proceed... and picks up where it left off! It either works, or I'm back in a debug window fixing what failed. Total time from thinking of a test to working code, often less than 5-10 minutes.
Please do show some measures.
This work was the genesis of IDEs.
Yes -- it's advanced alien technology. Vim, pfffft!
(Joking of course, but there's no reason a Smalltalk environment could have a Vim-behave-alike editor, but even better, e.g. with semantic knowledge of the code instead of just words and chars).
- file metaphore is limited, object are marginally better
- dynamic language instead of edit/compile/run
- infinitely more humane than C/sed/m4/awk/perl hybrid interactions
 There's a unix book about how to see it as an IDE, I do believe that long ago, BSD era, things were smaller, cleaner and better integrated. But I still hold my point
On that GH repo I see:
> Raspberry driven by WiringPi library
> Arduino driven by Firmata, soon
> Beaglebone, soon
Has anyone played with this?
So how close are the two in reality? Is the syntax from your standard Smalltalk-80 textbook largely portable/compatible to Pharo, or is Pharo merely "inspired" by Smalltalk?
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").
I believe that there are attempts to tackle these problems but what is the status?
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.
I am more hopeful about Bloc, however. The stack is not any more insane than that of a web browser.
This is not about having too few contributors; this is about different priorities. This is why Pharo remains an obscure project on the margins of the industry, despite all its potential.
In 1980, Smalltalk had some of the best documentation of any language out there. In 2019, it basically has none. By 2019 standards, Pharo 7 ships without any documentation at all. That's a game-stopper.
Pharo 7 looks really polished. It sounds like the design team put in tons of hard work over the past year and half to produce this release. Moreover, since it's smalltalk, Pharo is also probably very powerful for both web and desktop development. BUT NONE OF THAT MATTERS IF DEVELOPERS CAN'T FIGURE OUT HOW TO USE IT!!!
(pardon the all caps, but I want to emphasize my point)
Here is my message for the development team: if you really want developers to start building stuff with Pharo, then you absolutely must (1) write detailed, soup-to-nuts, high quality docs for web design and (2) write another set of detailed, soup-to-nuts, high quality docs for desktop GUI programming.
The Pharo book doesn't cut it--not even close. It's not a very good book. The Pharo MOOC doesn't cut it--again, not even close. Who wants to learn that way? ProfStef is just a fancy hello world; it's really not a tutorial and it doesn't lead anywhere.
I realize that what I'm saying comes across as pretty strong medicine, but please understand, that's because I actually think Pharo looks amazing and would like to use it.
In my opinion, you should stop development on Pharo and document what you've built instead. Write docs for a year. Today's release announcement states that the Pharo 7 team closed 2142 issues. Brag in 2020 about the fact that you wrote 2142 pages of documentation and tutorials over the past year. Make your documentation coverage as thorough as your testing coverage.
Imagine what might happen if Smalltalk 2020 was as thoroughly documented as Smalltalk 80.
Just wanted to add, there's quite a lot of documentation in the form of class and method comments, which could be (a starting point for) reference docs if dumped to (even static) HTML. The fact that I can't read about the methods of Collection class in the browser, like I can do here: https://docs.python.org/3/tutorial/datastructures.html or here: https://docs.racket-lang.org/reference/pairs.html?q=list#%28... or https://ruby-doc.org/core-2.6/Enumerable.html (or basically with any other lang) in 2019 is very wrong in my opinion :(
Even after I run the image, the browser doesn't make for the best tool to learn the overview of the system. Methods are tiny and a lot of them and you must click each one in turn to see the docstring. It's not easy to know which class is in which package or why. A lot of the classes have no docstring, but are described in some the ancestor class, and there's no way to display dosctrings of a group of classes at once - instead, you have to click through them manually. Various search tools help, but it's also not immediately obvious where they are or how to use them.
The system gets infinitely more discoverable once you install Roassal, which has tons of very useful example visualizations. But it's not installed in the default image, you need to know you need it and know enough Smalltalk and Pharo to install and run it and then how to modify the examples to make them useful for your current exploration area.
Anyway, that's how it is: painful to learn. It's great if you have someone to take you through the whole thing, but that doesn't scale, while the rate of change renders non-reference-like docs (Pharo by Example, Deep into Pharo) obsolete very quickly. Putting Pharo-devs effort into actually documenting the classes and then exposing these docs in accessible HTML is something I would really love to see one day...
Have you seen  and specifically ?
Do you have a particular example of a site where the kind of documentation that you would like to find is published for other language (lets say Python)? This could help to understand better which are the expectations and why current books and MOOC are not enough.
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.
GUI documentation will likely never show up: the current graphic framework is outdated, subject to deprecation and no subject to improvement since Athens low level layer was left as it is. It may or may not be replaced by Bloc or something else. I don't thing anyone is willing to write documentation when there is not clear direction regarding the GUI framework.
Isn't it crazy for this not to be solved yet?! That's a long time - don't remember exactly, but I started with Pharo 1.4 IIRC, and it was bad back there already, then juz got worse.
Is there a blog post detailing a) all the kinds of GUI frameworks that are out there and how advanced their development; and b) what approaches were tried and abandoned, when, and why? I know it's much to ask, but, at this point, I feel the lack of progress in this area should become a much higher priority, and a blog post like would help in recruiting people for the effort.
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:
^ 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.
I think it would be not too much work to parse out this kind of information (Class comments, methods and method comments, structure etc) and spit it out as a web page that could be hosted somewhere. Do you think this would help, at least somewhat, to bridge the divide with new users?
There's a book, "On to Smalltalk" that actually did a decent job of getting you started, but it's decades out of date now.
Anyone experience anything similar?
So you can learn Smalltalk with Pharo and then get into the big boys Smalltalk.
However expect the typical enterprise projects where Oracle DB licenses are footnotes on the overall budget.
How was your experience?
All and all I found the killer really was the ability to store situations where an exception was raised and being able to replay it later. It saved a ton of time for debugging.
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. :)
Is that true? VisualWorks isn't used more places? Where are you getting that information from?
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.
 : https://pharo.org/about
> Pharo is a pure object-oriented programming language and a powerful environment, focused on simplicity and immediate feedback.
and seeing the initial screenshot on the announcement, I thought that this was a joke post. How you can call this "focused on simplicity" while showing that horrific hodge podge of a screen shot is beyond me.
One aspect of simplicity is its minimal syntax...
You can find examples of people using Pharo in production (and far more examples of people using other, more industrial-grade Smalltalk dialects), but I personally haven't been able to think of a way to use it on real projects. But that doesn't mean that it isn't worth studying.