Honestly my experience at work was mostly with Visualworks. But I've been using Pharo in two side projects and I'm loving it. It became one of my top 3 programming languages I've ever used (together with Scheme and CL). It's impressive how much this rather small community achieved, thanks for the awesome work and this new release!

Also since most of the time developers spend debugging programmings, today I think languages should be designed with improved debugging features in mind. Statically programming languages are doing great progress here (always heard great things about error messages from Rust). Smalltalk and Common Lisp OTH, besides having nice error messages, also have exceptions with resumable semantics. The hability to always get a debugger during an exception without unwinding the stack is such a huge help (specially for dynamic languages), allowing one to fix a running program and continue working.

I maintain/develop a complex Smalltalk GUI desktop application and rarely restart it during development (which always take a while, since stuff like connecting and loading data from the database takes some time). Also I can always fire up the debugger to inspect objects I want to change (like dialogs etc), edit code and run it in any frame of the stack (like a REPL everywhere) etc. Maintaining this codebase in a dynamic programming language with exceptions that use the traditional termination model would be a nightmare, every crash would require a restart, and you don't have a compiler to help you. It's no surprise that people just turned to statically typing for this kind of system.

The sheer oddity + lack of real world example code floating around made it feel impenetrable. To put it into perspective, picking up Rust and writing entry level but real world applications was a walk in the park after coming to terms with the ownership system.

For learning Pharo (while not working at a company), I've learned that going to ESUG [1] and Pharo Days [2] (2 conferences) is the best way to actually learn. On ESUG there are many professional Smalltalkers, including people that write Pharo. And on Pharo Days there are many OG Pharo devs. They can teach you certain things much quicker than any course can.

For example, on ESUG, I was shown how to write a debugger extension on the spot for a particular debugging case (with animations) that had no good working debugging support yet. It was amazing to see how quick people can develop it when they have strong knowledge on it. The fact that the language is inspectable helps a ton.

Another way to learn is by asking many questions on their Discord channel [4]. The community seems really active there and I found them to be really friendly. The Pharo website [5] sort of understates how active their spun off communities are as they simply mention that they exist, but the site doesn't really convey the vibe of how lively the communities are. I'm not sure how one would go about that, but it's a shame you can't directly see that from a website.

[1] https://yesplan.be

[2] https://esug.org

[3] https://days.pharo.org

[4] https://discord.gg/QewZMZa

[5] https://pharo.org/community

Also, I'm all onboard having a UI environment for programming, but it needs to have great keybindings that follow platform HIGs, and at least my Pharo 10 experience of the window management was really bad.

I wrote about this some https://nikhilism.com/post/2021/experiencing-smalltalk/

That said, it looks like you end up with a million windows to do anything. Seems like the UI could be better UX'd, no? Guessing this a community that would treat such a comment as harassment.

as for the million windows, if you go that from my videos, then i'd like to point out that the interface has indeed improved since. for one it added the ability to group windows with tabs: https://youtu.be/GGJZeajjWGU?list=PLqbtQ7OkSta0ULYAd7Qdxof85...

(interestingly, that video is older than mine, so it seems that i just hadn't discovered this feature yet)

I also fear that leaning so heavily on a closed, corporate platform like Discord as the community hub may lead to tears in a few years. If you're leaning into the idea that "the community is the documentation," you're at Discord's mercy for community sustainment, on top of the already hairy problem of surfacing solutions from within the depths of a long-running discussion forum. Sure, running everything off of mailing lists + IRC like older open source projects do would be a clear step backwards, but being stuck with Discord has been a mild turn-off for me.

Finally, it's worth noting that development is spearheaded by folks in France and Latin America for whom English may not be their primary language. That doesn't affect their ability to do good work! It's totally worth reflecting on how something attempting to approximate natural-language programming in English ended up forked outside the Anglosphere! But I also feel like it'd be worth having an editor take a cleanup pass at future versions of the main ebooks. I've got both the books that Alexandre Bergel published through Apress, and they're both solid, but if the first-resort resources were up to the same standard, I think perhaps fewer people would come away with an unfavorable impression. Of course, that's over and above simply keeping them up to date as development progresses - I believe Pharo by Example is still on version 9?

Pharo has Iceberg integration. I always used the the functionality of Iceberg that said to load the repository from the .git folder itself as opposed to the repository living in the image. That way, I could do git from the command-line, which is especially important for rebasing as Iceberg doesn't have that feature yet.

I've noticed when it comes to Pharo, you need a hacker mentality. Because it lives in a VM, there are a lot of system programming concepts floating around. It's handy if you have that type of background.

Discord isn't the only part of the community. In Europe, the real backbone of the Pharo community is the academic world and the conferences they organize.

There are small communities outside the Discord having meetups and whatnot. Would probably be nice to have a Discourse-instance for a more documentation-like meeting place, but that requires money and volunteers doing moderation.

I enjoy that some docs and other resources aren't expressed in US:ian advertising lingo. It's not a bug, it's a feature.

Their lineage goes back to the Alto when people were imagining what interacting with computers even meant, and what metaphors from the real world make sense to apply to collections of bytes.

Rust is radical in some ways, but it's fundamentally a creature of the vaguely Unixy paradigm we all live in today. I miss the weird world of possibilities we used to have.

I would argue that this lineage of computing isn't as arcane and out-of-reach as people might think.

Much of the "obvious" promise of Smalltalk / object-based runtime environments — specifically, all the UI stuff it enabled — was too expensive / high-overhead initially, for it to have much penetration in the microcomputer or the mainframe/batch processing space; thus relegating those specific ideas to academic experiments in workstation productivity.

But fancy object-based UIs weren't the whole of what this lineage of computing was about. Microcomputer and mainframe systems were built as descendants of this lineage, repeatedly, and many of them were even in common use; but it might be harder to recognize them as such. It's the less-obvious, more low-level/internal architectural things they inherited.

If you ignore the specific assumption of a UI or "strict" OOP, and instead just consider this lineage as anything fitting these criteria:

1. systems that booted into a live runtime bytecode VM, usually de-hibernating the VM state from a memory image;

2. and then exposing a shell that was more of a REPL than a command language, allowing interoperation with the data that defined the state of the VM on a high level,

3. where the "operating system" within the runtime is fully exposed to you (rather than being a black box with a whitelisted FFI API); but where each data structure within that "operating system" is protected due to the common runtime of the OS + userland, enforcing ADT-defintion-time abstraction layers in the way it allows clients (including the REPL) to interact with any given object/ADT...

...then you could say that all of the following are part of the lineage:

• BASIC — especially the BASICs on microcomputers that booted to BASIC, or had BASIC on ROM, and never ran DOS (published software for these computers, was usually just precompiled BASIC bytecode!)

• Object Pascal / Delphi

• Emacs

• most SQL databases, but especially Ingress

• MOOs (object-oriented MUDs)

• Plan 9, despite its Unix roots. (Especially applicable insofar as you could consider "a runtime and OS as toolkit, and applications as LEGO with clear exposed seams that the user can pick apart and remix" an additional criterion.)

You can usually recognize these systems, because there's no way to get anything like a machine-code monitor / debugger on them; instead, the runtime itself usually exposes bytecode-level (or interpreter-level) monitoring / debugging, in a way that doesn't allow you to break the runtime's assumptions through it.

A long time ago I experimented with making web apps with Pharo, fun, but I wouldn’t use it in production.

When I saw this announcement I was motivated to update my Pharo NLP library https://github.com/mark-watson/nlp_smalltalk but I may not. Many NLP tasks are now done infinitely better using deep learning and LLMs.

I just looked for OpenAI API support and found 2 year old Pharo project library https://github.com/pharo-ai/open-ai and maybe more promising 1 year old project by Bracken https://github.com/brackendev/OpenAI-Pharo

EDIT: to be fair to Pharo, I am not really a Smalltalk person. In 1983 someone at Xerox arranged for me to get a trial Smalltalk system on My Xerox 1108 Lisp Machine, and I removed it within a few weeks.

not sure if I understand you, but you have the code of the whole system at your fingertips. Which is certainly "real world" because you are running it :)

the success page lists 53 projects. only one of them came with a direct link to the source. one included an un-clickable link. one linked to a non-english website where i could figure out that it was licensed under the LGPL, but i could not find the link to the source.

a surprise was that DrGeo which is known to be Free Software links to a dead website. grafoscopio which i also believe to be FOSS as well has a dead download link on its website.

several other projects had dead links too.

the only source i found was for

HoneyGinger: https://github.com/tomooda/HoneyGinger

OpenPonk https://github.com/OpenPonk

and record: https://github.com/estebanlm/record (7 years old)

btw, DrGeo is here: https://github.com/hilaire/drgeo

that is three source examples under active development

for a project as old and as large as pharo is that is surprisingly little.

more accessible source examples are needed to attract developers. especially given the difficulty to get used to the pharo developer tools.

i have actively explored working with pharo. i just could not find any useful apps that i could use and contribute to. and i had no ideas for an app that i'd be interested enough to create from scratch.

for a while i even tried to use it as a desktop and used an app that provides a commandline inside pharo.

the primary problem was that upgrading to a new version of pharo each year was difficult. given the image based development you tend to start with a current version of pharo and then keep to that version until you are done.

Then you must already know more than me, about what's available now.

Too much? https://github.com/feenkcom/gtoolkit

> … given the image based development you tend to start with a current version of pharo and then keep to that version until you are done.

I think of it as image based development: not image based version control.

i mean the lack of version control inside the image can be considered a problem, as you have to connect to external tools go get it, lest you save a copy of the image as a version (which is what i would call image based version control), which that is not practical at all.

but that is not what i meant. i was talking about the problem that when i develop an application in pharo 11, but then i want to move the development to pharo 12, that amounts to a lot of work, so i don't do it but i'll stick to pharo 11 until my app is done.

there is no tool that would just take every change i made to the original pharo image and apply it to the new one.

you know like docker where your base image is immutable and changes to that image are saved in a separate image that is layered on top. so that you can replace the base image while keeping your changes.

What about Smalltalk?

All your interaction with the IDE is implemented in Smalltalk. For each of the changes you want to preserve, figure out which UI class is used and browse the code to figure out how the UI class makes those changes. Then copy what the UI class does into a workspace script, save the script, and file-in to a clean distro image to check that it works.

Here's an example of a little script being filed-in to load a program, do clean-up and save the image:

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

You have Smalltalk the language, which is this [] big, and Smalltalk the environment and class libraries, notably the GUI system, which is this [.....**.....] big.

And, sure, you have all of the source code, but, for me, the source code may as well be organized in a stack of index cards. You get the individual methods, but not the sweeping picture. I can learn a lot more scanning a file full or source code, compared to the little snippets of code you're presented with screen by screen. Just being able to scroll and absorb is useful.

But even then, especially being OO, with lots of abstraction, tracing through the GUI code, blind, is very difficult. You end up at top level, "do nothing" abstraction classes. Much like in Java, where everything you click on is an interface, which doesn't tell you a whole lot.

Navigating a Smalltalk image is a skill all its own.

Finding documentation to learn to use this absolutely obscure system is near impossible. I seen an announcement about a Pharo release a couple years ago and was like "huh, that sounds cool." Proceded to download it and had no clue about anything. It is not at all like any other IDE.

Learning it might not be hard, but when the IDE is absolutely different from anything else you've ever used, combined with very little documentation that speaks to how to do the basics, it can be a very mysterious and difficult thing.

Rust is like any other programming language, in that you write code in a file, then compile it. Yes, there's other stuff to deal with in between and it can get way more complicated. But the IDE is the real culprit, combined with documentation for a developer to learn to develop real applications with, that makes Pharo infinitely more difficult in my personal opinion.

I guess to simplify this a little with an edit. If you already know another programming language, learning Rust is not fundamentally different. Some parts of it will be difficult like the borrow system and stuff that's very Rust centric. But in most ways it behaves like a lot of other languages in terms of using it at a bare bones basic level. Pharo is ... otherworldly in that nothing else really compares, you have to learn a completely different paradigm for how to program it, and that is the difficult part imo.

I think there is a valid reason for tools like Pharo to exist, I don't know the answer to how to improve the situation outside of a (selfish) desire to see better beginner documentation that talks about using it for people that have zero knowledge of Pharo and similar tools. Explain it like I'm 5 type stuff. I suspect it all becomes easier once the general primitives are explained but until they are there's an inscrutability to it.

I think that's a pretty neat introduction to the very basic basics.

Once one gets over the initial hurdle of the syntax, message passing and how to use the GUI to create new projects and objects one can usually just surf around in the image and look for examples to figure things out.

The real difficulty is in trying to make sense of the whole ecosystem, including the strange runtime-IDE-hybrid approach.

Also lack of retina display support put me off. Of course it is purely cosmetic but when it's literally the only app I used that looks like shit, it is sufficient to nudge me away. Maybe fixed now, not sure.

The tools are how we find functionality that can be re-used and re-purposed to do what we need. A lot of exploring and reading existing stuff, less writing new stuff.

> Smalltalk files are not plain text but rather images (or something)

Mostly Smalltalk files are plain text files!

There's a plain text log file with a replayable record of what you've been doing. There's a sources file with the source code. There are plain text file outs and change sets.

There's the VM like the JVM — not a plain text file.

There's the image, a cache of byte code (like Java .class files, Python .pyc files) and application state — not a plain text file.

With a previous Pharo version:

    $ bin/pharo --headless Pharo10-SNAPSHOT-64bit-502addc.image hello.st

Pharo10-SNAPSHOT-64bit-502addc.image is the image.

hello.st is a plain text file.

    $ cat hello.st
    Stdio stdout 
        nextPutAll: 'hello world'; 
        nextPut: Character lf.!
    SmalltalkImage current snapshot: false andQuit: true!

Postgres has to deal with images (backups) and versions (migrations). Maybe selling image-based systems in both cases needs a little work or formalisation (best practices and all that)?

Image-based systems seem more about data management rather than code management. Just some random thoughts

"Within each project, a set of changes you make to class descriptions is maintained. … Using a browser view of this set of changes, you can find out what you have been doing. Also, you can use the set of changes to create an external file containing descriptions of the modifications you have made to the system so that you can share your work with other users."

1984 "Smalltalk-80 The Interactive Programming Environment" page 46

"At the outset of a project involving two or more programmers: Do assign a member of the team to be the version manager. … The responsibilities of the version manager consist of collecting and cataloging code files submitted by all members of the team, periodically building a new system image incorporating all submitted code files, and releasing the image for use by the team. The version manager stores the current release and all code files for that release in a central place, allowing team members read access, and disallowing write access for anyone except the version manager."

1984 "Smalltalk-80 The Interactive Programming Environment" page 500

https://rmod-files.lille.inria.fr/FreeBooks/TheInteractivePr...

Pharo should generally work on Wayland, so there will be more things going on, probably.

[1] https://cuis.st/

Also it doesn't run on wayland without explicitly setting SDL_VIDEODRIVER=x11

Also can't find a way to increase menu font sizes.

Upd: ok, I managed to change the directories (they need to be created beforehand). Somehow empty ~/Pharo/scripts is still created every time the launcher runs. Please fix.

Yes, even the fonts themselves are vector graphics. You can use a fancy cursive font, rotate a text window, and then zoom it in or out - with total clarity.

But a singular testament of Pharo is that it this amazing environment, with all this heritage, tickling many of the more popular "CS folk" buttons.

It's an active, busy project, with lots of committers.

And yet, "nobody" uses it.

The Pharo folks live in their sandbox, eating their dog food, making Pharo more Pharo than ever, but it seems to only be uplifting folks making Pharo. Pharo is built for Pharo makers to make Pharo, and they continue make Pharo a better place for them to live and do their work.

I'm certainly not going say that its because of X or Y or Z. Just that, it "is". It is "not used" in the large. Sure, folks use it, they have their success stories like any project does to some extent. But the larger "hive mind" of the "internet" hasn't seemed to have caught on, or have tasted it and moved on to something else.

So, at 30,000 feet, despite all their work, something is not quite clicking.

Some of this is just down to the philosophy of Smalltalks. To program in a Smalltalk is to make Smalltalk. You can't really separate the creation of the system from the creation of the application(s).

With that in mind, it's hardly surprising that few people who aren't contributing to Pharo use Pharo—it may not be just that it hasn't found mainstream appeal (which is true) but also that most people who pick it up and start using it seriously end up becoming contributors.

I assume that step 1 towards parallelism, at least on the image side, would be going through the class library and making sure everything is thread-safe. I'd love to know where one would even get started with that effort. The Roar project claims to support Pharo 1.2, which doesn't seem to be very far after they forked from Squeak, but obviously a lot has changed since then. And the challenge is that Pharo is still rapidly developing all the overhauled classes that distinguish it from Smalltalk-80.

Meanwhile, if I want to play with parallel image/REPL-based programming, I can go over to Common Lisp and, while lacking an equally coherent GUI, be able to load up bordeaux-threads and off I go.

Who does Pharo want to compete with? Maybe developers think they shouldn't compete with other platforms? With the amount of real Pharo apps right now even on GitHub, it would be extremely difficult to "sell" Pharo to any decision maker.

Many companies that buy software don't care about programming languages, they care about functionality and price. With Pharo you can show them immediately what the application could look like and how their processes could be implemented. Fast development means you can sell at a lower price and reach customers that can't afford more 'classic enterprise'. You can also reach customers that do work in quickly changing regulatory environments, like insurance.

When you've banged out the frontend and some logic you return to your office and figure out things like database schema.

Pharo is specifically designed for commercial and industrial applications and not as a research environment. Partnering with private capital has been one source of funding for the project.

Let's not get stuck in a local minima on how to do programming. There could be better ways not yet popular enough. Smalltalk came out of an environment of innovations that were ahead of their time.

EDIT: while doing the Pharo mooc, I was able to create a DSL for what I understand to be D&D dice representation without using special metaprogramming syntax of the language or parsing and tokenizing strings. Just plain old OOP of the Smalltalk/Pharo flavour. This were just basics btw

Meanwhile the nasty statically type checked languages lowered the pain level with non-nullable and type inference for local vars.

another problem that squeak had was that it was built on top of old images, containing objects that date back to the beginning of squeaks history, and possibly even older than that, and because of that it was (at least at the time) not possible to verify the ownership and license of all the source that the image was made of. for some objects the source was even lost altogether. this made squeak incompatible with FOSS licenses and it was a reason why it was not included in linux distributions. which is one factor that limited its spread among developers.

one of pharo's goals was to remove those old objects and unverified source and make it possible to build new images purely from a verifiable source.

from a certain perspective, the inclusion of those old objects creates a certain sense of awe, considering who were the people that worked on smalltalk that created these objects, whereas pharo in that respect feels more sterile.

I don't know Pharo at all, but "not pragmatic" often means just "too different from what I'm used to"...

It is very oriented to develop tooling of tooling of tooling and we all work with files nowadays, not wirh images.

I want to like Pharo, but that creates other frictions with tools such as Git (I know you can use Git, I tried, it is just not obvious how the workflow works).

Also, it has a full set of APIs for GUIs that noone knows in contemporany programming.

It is a pitty bc I really think it could really excel at interactive and live programming. However, when I drop Python there even if supposedly inferior, I can have my editor and iterate fast.

I can invent even some kind of hot reloading that works well enough. And the result (the pragmatic result!) is that overall it ends up working better for me.

I really want to like Pharo. I find it super cool. But... every time I use it I end up getting stuck. C FFI, I am not sure how to do it (my fault probably!), workflow is unobvious even if more powerful.

So I end up wanting to do some interactive stuff but I always get stuck.

Also, the software deployment with Pharo is weird. It looks weird. It should look like a regular app when I launch something, not like a marsian environment.