
Pharo: An immersive programming experience - signa11
https://pharo.org
======
tonyg
I've found a good way to approach Smalltalk systems like Pharo and Squeak is
to remember they're _whole systems_ , not just languages with a bolted-on IDE.

I like to think of each running instance as more akin to a Unix virtual
machine than anything else. You end up using "in-image" version control
systems like Monticello just the same way on a Unix server you use "in-
operating-system" version control systems like git.

~~~
em-bee
the only thing i miss is a terminal. some time ago i actually found one, but
it needs porting to pharo.

greetings, eMBee.

~~~
draegtun
Here's a new Terminal emulator that appeared this month -
[https://blog.lxsang.me/post/id/24](https://blog.lxsang.me/post/id/24)

~~~
em-bee
ohhh, you are my new best friend!

i love the serendipity of this topic coming up just days after that post you
found when i have not looked into it for a few years after trying for a few
days to get that original squeak terminal to run in pharo.

greetings, eMBee.

------
AlexeyBrin
There is a Pharo MOOC currently running:

[http://mooc.pharo.org/](http://mooc.pharo.org/)

[https://www.fun-
mooc.fr/courses/course-v1:inria+41010+sessio...](https://www.fun-
mooc.fr/courses/course-v1:inria+41010+session03/about?platform=hootsuite)

The original course is in French (dubbed in English) with English, Spanish and
Japanese subtitles.

~~~
agumonkey
There's also a website with a public archive iirc

------
mark_l_watson
Good to see this make the front page of HN. I only spend a few hours a month
using Pharo (some working on my open source NLP project, but mostly just
trying out new packages and demos released for Pharo).

Other comments here are right: think of Smalltalk as being the complete
computer. When I use Pharo I usually put it in full screen mode and don't
think about the macOS or Linux host.

~~~
okket
It’s not that Pharo discussions are rare on HN...

[https://news.ycombinator.com/from?site=pharo.org](https://news.ycombinator.com/from?site=pharo.org)

~~~
wsc981
I've been visiting HN for quite a few years now, but somehow this is my first
encounter of a topic on Pharo. The language seems interesting to me, so I am
glad it was posted today.

------
sn41
Squeak is the most delightful IDE I've worked in. I liked the idea that the
IDE, including the interactive debugger, was available to the user to program.
I hope Pharo gains more traction and becomes popular at least in teaching
environments.

~~~
gameswithgo
>. I liked the idea that the IDE, including the interactive debugger, was
available to the user to program.

a similar concept exists in F# type providers. it doesn't always work out well
in practice but there is a ton of promise there.

~~~
mpweiher
In what instances/how does it not work out well in practice?

I've only read the hype, and it sure reads well... :-)

~~~
Risord
I have a dream that some day we have statically typed language which would
have first-class types with some compile time meta programming.

For given example data, type providers output just something and typically
it's 95% what you want. But how to fix that 5%? You cannot just say that
"Type.Property, could you please be an integer". Instead of you have to tweak
example which in some case is just fine but on some cases it's not possible at
all.

Example: you use these SQL libraries which are based on type providers. You
have some clear schema and it's just works. Then some day you would like to
use runtime defined columns but at that point you have to opt out from that
type provider library (at least for queries related to that table).

I still love working with F# but I don't use much of type providers. I think
they are like proof of concept that compile time meta-programming can be
provide real value but it need still more freedom.

Edit: I use SQL library called Rezoom and while it has it's limits it has
given great benefit during development. When you change DB schema every
effected query and model transformation gives compile time error. Value there
is real.

------
nerdponx
For anybody who's used an "immersive" programming environment, like Smalltalk
to a Lisp machine -- what's the advantage? It seems like the ability to mutate
the whole world would just be asking for mistakes. I can barely keep a clean
Python REPL. Do you restart your whole machine to run your test suite?

~~~
mikelevins
You have two questions:

1\. What's the advantage?

2\. How do you manage the state of the environment?

The advantage is programming-as-teaching, as opposed to programming-as-
carpentry. What I mean by "programming-as-teaching" is that old-fashioned
Smalltalk (and Lisp) enviroments like Pharo are designed to support a style of
development where you build a program by starting up the runtime and teaching
it interactively, incrementally, how to be the program you want.

(What I mean by "programming-as-carpentry" is the more widespread and better-
known model in which you are essentially working to build a planned artifact
from a blueprint, and your development environment is analogous to a workbench
or toolchest, rather than a student.)

If you don't like programming-as-teaching, then it's not an advantage. Most
people don't work that way, but I think that's mostly because they don't even
know it's an option. I'm not saying that everyone would prefer programming-as-
teaching, but it gets so little exposure that I think it's a safe bet that
more people would like it if they knew what it was.

I prefer programming-as-teaching over the alternative. I am dramatically more
productive when I can work that way. I've been one of those fabled 10X
programmers, as confirmed by VCS statistics, when working with such tools. It
wasn't because I'm so brilliant or because I have amazing magical powers; it's
because we were working with that kind of environment, and I knew how to use
it and the other programmers didn't.

So, in brief, the advantage is that if you have such an environment and can
use it effectively, you can be dramatically more productive. It changes the
feel of programming from "let's build this variant and see how it turns out"
to "reach over and correct that student's posture." The cycle of iterations
becomes very fast, so fast that sometimes the duration of a cycle is
imperceptible.

How do you manage the environment? First, let me acknowledge that modifying
your working environment willy nilly is indeed a problem. The solution is that
you don't do that.

Instead, you start from a known good system image. Environments like Pharo and
other old-fashioned Smalltalk and Lisp environments offer a feature that can
save the entire state of system memory to an "image" file. If you start the
environment from an image, you get an in-memory state that is an exact
duplicate of the state the environment was in when saved--right down to the
positions and contents and activation states of all the windows. You start the
image, and you're in the environment, exactly as it was when you saved it.

The way you manage incremental state changes is that you make a reference
image that contains a known good state. A common choice for a reference image
is a clean, unmodified release image. Then you make any site-specific
modifications and customizations and save the result as a reference image as
well. Then you save a working image based on that reference image and make
your changes to the working image.

This practice enables you to easily recover if you get into a bad state. It's
very fast to kill a bad session and restore a reference image. For example, a
Pharo 6.1 image launches in under half a second on my older iMac. Clozure
Common Lisp starts from an image in a similar amount of time.

When I've done ongoing serious work using this kind of system, we kept orderly
collections of reference and working images--reference images that served as
checkpoints in case of trouble; working images in which we had all the stuff
we were working on loaded up and ready to go.

Besides making it quick and easy to resume yesterday's work, and to recover in
cases where we messed up, images also served the useful purpose of enabling us
to capture precise dynamic states of work in progress. For example, if a rare
bug arises, I can save a working image with the problem on the screen, and
give that image to my colleagues. They can start up the image and immediately
see the problem state on their screens, and use the introspective capabilities
of the development system to diagnose the problem.

But I guess that's more an advantage than a how-do-you-manage-it observation.

~~~
jacobsenscott
Where does testing fit into programming by teaching? I've worked with people
who write some code, refresh the screen, write some more code, refresh the
screen, etc. Is that programming as teaching? They definitely produce at least
10x more code than I do, but it is instant legacy code with no tests. Do you
go back and write tests after everything looks like it is working?

~~~
mikelevins
Other comments have pointed out that test-driven design was actually born in
the Smalltalk community, which sort of answers your question, by implication,
at least: it's standard operating procedure to write a lot of tests as you go.

Indeed, in my experience, any expression I write in the repl is more likely
than not to be a test, or part of a test.

The way I normally work is with a running Lisp image and one or more files
open in editors. For greenfield development I usually create a project and
write a loadfile to load any library dependencies I expect to use. Once that's
loaded, I write some expressions to build some test data, and then some more
expressions to operate on the test data. I evaluate the test-data constructors
and then fiddle with operations on the data to assure myself that what happens
is what I expect to happen. Basically, I start with an idea of how to
accomplish something, sketch out the data structures and APIs I think I'll
need, and start exercising them to see what I got wrong, what I need to add or
change.

The contents of those source files gradually become the source code of my
program and of the test suite that go with it. When the project is new and
small, the sources are a few files with a small number of lines of code, and
the organization is minimal and loose. As I flesh out the program, the source
files grow more numerous and more formally organized.

As a project gets complex, I may choose to save working images at points where
I'm confident that the state of the system is good. Such images enable me to
start the Lisp environment with all of my code already loaded and ready to
use. I can then work from that point in the same way that I've described.

The normal way I work on anything, unless the tools I have to use prevent it,
is to have a work-in-progress running, and use variable references and
function calls in the repl to query the and modify the dynamic state. For any
expression more complicated than a short one-liner, I actually write it in a
source file and copy it to the repl (actually, I usually use Emacs with SLIME,
so "copying it to the repl" really means typing a keystroke or two in the
source file).

One of the differences between old-fashioned Lisp and Smalltalk systems and
newer systems with repls is that the old Lisp and Smalltalk repls are capable
of doing every part of program development--defining and redefining functions
and data structures, running and debugging code, inspecting dynamic state,
catching, inspecting, and modifying erroneous code, and building the finished
app for deployment--all by typing expressions at the repl.

To put it another way, the entire language and development tools and all of
your application's internals are always in memory and completely accessible
from the repl.

It's not that you would normally do all your development in the repl, although
you could if you wanted. Rather, the important point is that, because the repl
can do anything the language and development tools can do, there are no
artificial limitations on what you can do from the repl. Outside old Lisp and
Smalltalk systems, every repl I've used always imposes some restrictions--some
things you can't do from the repl. Invariably the way I discover this is by
needing to do something in the repl and finding that it won't let me.

~~~
jacobsenscott
Thanks for the detailed explanation. I haven't used smalltalk, and I think
making the mental shift from "source files and an interpreter or compiler" to
"working in the image" is something I'll need to experience to fully
appreciate.

~~~
mikelevins
It's easier to grok if you have a friend or colleague who is familiar with it
and who can show you the ropes.

Also, there's no guarantee that you'll find it congenial. Some people profess
to prefer programming-by-carpentry, and that's fine, of course.

In fact, maybe it's better for your sake if you don't like it. The great
majority of programming work is programming-by-carpentry. You might find that
you really like programming-by-teaching, and then spend the rest of your life
pining for the opportunity to work that way.

------
mwnorman2
I left the Smalltalk world years ago (for Java ... hmm was it a win?) but the
thing I miss the most is ... reading great code. Within the Smalltalk
image/IDE, everyday you read code that other folks - many with brains much
much bigger than mine - have written, and its great. A lot of the code I read
now (Java,Objective-C) is ... err ... brain hurt :-(

~~~
maltalex
> everyday you read code that other folks - many with brains much much bigger
> than mine - have written, and its great.

I don't think that it's a language thing. It's probably popularity thing most
of all.

In popular languages the quality of the _average_ line of code is pretty low.
Plus, you know, real-world constraints of real developers working under real-
world constraints....

------
Stratoscope
I wonder if anyone familiar with both Squeak and Pharo could give a brief
comparison between them, or link to one?

I don't have a specific goal in mind but have always been interested in
Smalltalk, and am not sure which one to try out. Thanks!

~~~
pjmlp
Squeak is the original descendent from Smalltalk-80, where they used the last
good image as a starting point for a bootstraped implementation of
Smalltalk-80.

Pharo started as a kind of Squeak fork, where they wanted to pursue other
ideas related to JIT, GC, compiler technology, traits and so on.

So basically both are Smalltalk-80 implementations, with Pharo trying to be a
more modern version of it.

~~~
Stratoscope
Thanks for the info! Very interesting about bootstrapping from the last good
image. An old friend of mine (now retired) was involved in Squeak from before
the beginning, and this reminds me that I've been meaning to catch up with
him. I bet he has some interesting stories.

I tried out Squeak about ten years ago, but never could get past the awful
bitmap font. Naturally, the first thing I noticed on the Pharo page was that
the fonts look nice! So I installed it on my WQHD ThinkPad to try it out.

The first thing I noticed is the way it responds to the TrackPoint. It is not
like any other application I have ever used. Instead of letting Windows
control the pointer position, it's doing something very different, I just
don't know what.

It's not so bad with the touchpad, but I don't use the touchpad except for
scrolling.

It doesn't support high DPI either, so the text is all blurry. Way better than
the old Squeak bitmap fonts, though.

I don't want to sound like a complainer, it just wouldn't be pleasant to
program in this environment when every other app and dev tool I use supports
high DPI and correct TrackPoint response, both on Windows and Linux.

~~~
scroot
The next-gen graphics system for Pharo, called Bloc, is still under
development but making good progress. If you can find some of the demos [1]
you'll see that things like text rendering are vastly improved.

[1]
[https://twitter.com/AliakseiSyrel/status/1050781535983550464](https://twitter.com/AliakseiSyrel/status/1050781535983550464)

------
miki123211
All is nice and well... until you need to code with a screen-reader. That kind
of sucks, as those IDEs obviously use some non-native controls and the only
thing the screen-reader can see is a blank window with no usable content. I
was once very excited about such projects, but I'm not anymore because I can't
really use them in any way.

With normal languages like Java etc. You can just use a different, accessible
IDE (i.e. Eclipse instead of Net Beans). That creates some problems,
especially when working with a team, but in the end, it can be done if you try
hard enough. Smalltalk and smalltalky things that try to be GUI only, no
command line at all, are completely hopeless, though.

~~~
qwerty456127
That's an important point but lack of screen-readers (or whatever) support is
forgivable at the early stages of a project that gives something conceptually
interesting in exchange. I just hope they won't forget about it later when it
gets clear that the project stabilizes and its future becomes clear.

~~~
thisrod
Smalltalk has been around since the 1970s, though. Given the things the
community is interested in, schools, video, sound, and so on, it's odd that
accessibility never came up.

~~~
User23
Most sighted persons really don't like thinking about blindness. It's not
because they are bad people, it's just deeply scary and relatively uncommon.

This is an area where Apple really doesn't get enough credit. VoiceOver has
absolutely revolutionized blind persons' ability to interact with consumer
tech.

For more technically demanding applications, the Unix philosophy is inherently
open to being made accessible.
[https://pjb.com.au/blin/](https://pjb.com.au/blin/).

As an aside, I personally really enjoy accessible websites, because they focus
on clear communication in the presence of a serious obstacle, rather than
assaulting the visual cortex with attention grabbing nonsense.

Edit: Also one could argue that ed(1)¹ is the pinnacle of accessibility.

¹[https://www.gnu.org/fun/jokes/ed-msg.html](https://www.gnu.org/fun/jokes/ed-
msg.html)

~~~
mwcampbell
Here's a blind programmer who actually did argue, in all seriousness, that ed
is the pinnacle of accessibility:
[http://eklhad.net/philosophy.html](http://eklhad.net/philosophy.html)

~~~
User23
Great read. Thanks!

~~~
qwerty456127
Isn't it fascinating how posting a seemingly-useless comment that is
guaranteed to be down-voted can provoke people to post interesting things in
response? :-)

------
atemerev
It is still unusable with HiDPI displays. The bug is raised for 5 years, and
as Pharo renders everything from scratch, it makes the UI pixelated.

OK, I will wait a few more years. I love Smalltalk, but I don't think I am
qualified to fix this myself, unfortunately.

~~~
philippeback
Not true, I work on a 4K screen and it is clean. Win10 latest. Windows VM,
some settings to tweak in Pharo but it works.

Upcoming is Bloc, which uses Mozilla2D as rendering engine and is vector
based.

Next Pharo UI will use it.

See [https://github.com/pharo-graphics/Bloc](https://github.com/pharo-
graphics/Bloc)

~~~
Stratoscope
I just installed it on my WQHD ThinkPad running at 225% scaling and everything
is blurry. It's definitely not running as a high-DPI-aware app. Are you saying
there are some settings I can tweak to fix it? That would be great.

The TrackPoint response is all wrong too, but one step at a time... :-)

~~~
philippeback
Looks like this in Win10:

[https://imgur.com/a/X9PcgZe](https://imgur.com/a/X9PcgZe)

Should be better anyway, but it is usable.

I already got it better but the VM has changed since and the rendering is not
as good (but is faster for some reason).

Vs IntelliJ, it sucks a tad.

------
mncharity
Pharo and VR?

Pharo's code browser is visually compact. The code too. Current VR HMDs have
only a small VGA-ish region of non-blurry pixels. Hmm...

Might be a good match. Emacs and IDEs with non-compact languages can be head-
sloshing. And the HMD OEM market is being dysfunctional, so higher resolution
is on the "I don't see a unicorn here - who cares about easily improving the
world?" slowmo snail plan.

~~~
philippeback
I have been coding in Pharo while in BigScreen on a Rift. Cool experience.
Better with the font size set to medium in Pharo settings.

~~~
mncharity
Neat. I (occasionally) use emacs in a trivial node.js-as-compositor stack on a
Lenovo Explorer on linux. With a 7px font, a pixel-aligned window, no temporal
supersampling (because low fps on an old laptop's integrated graphics), and
WMR's handwave 500px-ish diameter pixels-not-blurred-together region, it's
bearable, but far from competitive with a 1080p laptop screen. With subpixel
rendering (Explorer has normal non-PenTile subpixels), a 5px font is ok (but
not in emacs), but only across say 300px.

With better lenses and a better panel, an HMD might be competitive. But it's
not perceived to be market, and there's pervasive confusion about the
(minimal) GPU and (slow) fps needed. And there's only limited diy
infrastructure.

But I enjoyed live-coding a vr environment (hot loading three.js and react.)
At least with desktop mirroring, to flip-up to screen when the world broke.

Perhaps [https://pharojs.github.io/](https://pharojs.github.io/) ? Croquet
Project, Open Cobalt, and OpenQwaq are all dead, and 3dicc seems to have gone
closed-source commercial. Ah, ST - feels like the 1980's all over again. :/
But [https://github.com/ronsaldo/woden](https://github.com/ronsaldo/woden)
looks alive. And someone apparently hacked a bridge to Unreal. I wonder what
else is out there?

------
scroot
Pharo is what I want my personal computer to be like.

------
3rdAccount
Yayy! More mentioning of ST (and Pharo) on HN. I'm just a beginner, but am
slowly learning. So far the IDE is the only one I really like as it is one
with the language rather than an entirely separate entity.

------
geokon
A bit unclear from the landing page if it's an IDE with a REPL or if you can
edit the IDE you're running in..

Kinda sounds like an object oriented Emacs? Or what the creator of Nightlight
is trying to do with Clojure.

~~~
jplayer01
It's basically an open-source, interpreted, pure OO operating system. You can
make changes to the system's code while it's running, any part of the system,
and changes will take effect immediately.

~~~
tonyg
The "interpreted" bit isn't really true anymore. Smalltalk has been bytecode-
compiled since, uh, I think 1976, and the bytecodes themselves are JITted by
the Pharo/Squeak virtual machine these days. They're usually only interpreted
when you're using the debugger.

------
derReineke
Serious question though, what is immersion in the programming context? Is it
being only in the programming environment and not leaving? Wouldn't using a
web browser for documentation or stack overflow be a break in it? Why not just
have the windows one needs and configure your ide to be how you like?

~~~
seandenigris
> Is [immersion] being only in the programming environment and not leaving?
> The dream is never leaving, as expressed by the Dynabook concept. However,
> in the full expression of that dream, the browser et al that you mention
> would _also_ be inside the context.

In practice, things like using a browser for documentation is acceptable but
not super common because viewing in the IDE is so much more powerful in
certain ways (e.g. executable examples, finding "senders" of a message).

The idea is about having one's computer be "turtles all the way down" where
you have the same power to change and explore every layer of the system
without learning a whole new technology - from what we usually leave to the OS
(which Dan Ingalls said "shouldn't exist") to what currently exists in apps
(which Alan Kay and the creators of Smalltalk envisioned as services, which
didn't stovepipe possibilities/power down to a small fraction of what's
available).

~~~
derReineke
Oh I see! That would be pretty neat, actually. Is looking up documentation a
common feature in IDEs? I've never seen it before.

------
jiriro
Say I’ve developed (taught) an image - full of useful stuff. Now a new version
of Pharo comes out. How do I move that stuff to the new version?

~~~
finder83
I'm pretty new, but I've found a few ways. Most useful to modern development
is a package called Iceberg, which is a git interface...you can export your
classes/code/etc, commit them, and pull them into different images. You get to
choose what you export, so you can only export your code.

There's also Monticello which is similar, but uses different repository types
than git.

You can also just "File out" a class or package, which exports it to the file
system.

------
derReineke
I swear to God if Aragon takes over Castille while I'm programming my
immersion will be ruined! Needs to be 100% historically accurate!

------
ausbah
Can someone explain how a language can’t have primitive types?

~~~
tralarpa
If you are familar with Java: Just imagine all integers are objects from class
Integer and that int doesn't exist.

(Internally, they are actually represented as 31-bit numbers for performance
reasons)

~~~
jhbadger
Or non-hypothetically, integers in Ruby -- 5.methods shows that 5 is an object
just like anything else. But then Ruby has been called a modern Smalltalk for
this reason.

~~~
pjmlp
With the difference that cruffy Smalltalk still has better JITs available.

