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.
I agree with you. I've worked for a while at a company using it in production [1].
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.
I think Pharo would benefit a lot from having lots and lots of screen casts, since so much stuff is visual. I don't think something like ESUG is a sustainable way to spread techniques. A lot of stuff that is well documented in the Pharo ecosystem is old. A lot of the new stuff doesn't have great docs. Just reference docs and code is not enough. There has to be a coherent narrative around an API to put it together.
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 don't know how much has changed since then. but if pharo has changed so much that this screencast can no longer be used then that's a problem in itself. we are not going to gwt more screencasts if their halflife is to short.
Looking over the syntax, it seems that lines end with a period, much like in English. This makes much more sense than semicolon!
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.
why would it be considered harassment? it's not like your comment is any more critical than many of the others here.
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)
My initial burst of enthusiasm was dampened by the big gap between the entry-level introductions (ProfStef tutorial, the introductory MOOC) and the sheer complexity of everything the image includes. I'm not a big-time Java developer, I certainly appreciate the elegance of the language and dev environment compared to, say, Python, but that huge list of packages and their Baselines in the left pane of the system browser makes it really difficult to tell where to get started. I attended an online Smalltalk meetup recently, and one of the veteran Smalltalkers there was preferentially rebasing his code on Cuis because he felt Pharo had become too heavyweight.
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?
> and one of the veteran Smalltalkers there was preferentially rebasing his code on Cuis because he felt Pharo had become too heavyweight.
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.
Start with the Finder and the Examples-category if you want to know how to do something, don't browse the full package list in the hope you'll stumble over something useful.
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.
Squeak / Pharo are alternate timeline technologies. Maybe the one where Betamax won and Al Gore read the intelligence briefing.
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.
> 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.
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.
I would like to disagree with you, but I can’t. Pharo, and Squeak that it is derivative from, is an odd development experience.
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.
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.
I had a similar experience when I tried to learn Smalltalk.
Pharo By Example is a thing. I haven't read it, but I assume it is forked from or inspired by Squeak By Example, which made things click for me (at least a little).
IIRC, Squeak By Example is heavily Morphic centric, which is going to immediately diverge from other language Getting Started sections. Not sure if one exists but a Getting Started that focuses on just the Workspace, the Transcript and data processing might be a better introduction to those with experience in more traditional languages.
> The sheer oddity + lack of real world example code floating around made it feel impenetrable
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 :)
real world example means end user applications, not developer tools. i want to see how an application looks like that my mother could use, or that i could sell to my customer. websites. desktop applications that hide the IDE...
that's not the question. we are looking for examples that come with source that can be studied.
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.
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.
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.
it's not the code conflicts, but all the modifications i made to the environment. addons i installed, configurations i changed, windows i opened, code snippets i have in a workspace/playground. pharo is to much like a desktop, and switching to a new version of pharo is like reinstalling my computer and setting up my desktop from scratch.
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.
> there is no tool that would just take every change i made to the original pharo image and apply it to the new one.
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:
i would want to preserve everything. this is not solvable with a simple script. in docker this feature comes built in. everywhere else all i need to do is copy my homedirectory, and every upgraded application works with the data i have. smalltalks design makes this a magnitude more difficult, and in the end not worth the effort until i get an opportunity to work on a paid project.
Others have linked to the book collection, there you'll find walkthroughs of the basics, building web applications, tracking code in git, and so on. A lot of the common packages also have examples bundled that you can play around with and read documentation in.
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.
Did you try the MOOC? At first the environment may feel a bit confusing, but the videos in the MOOC help to walk through it, visually, and get familiar: https://mooc.pharo.org/
Learning Rust is at least an order of magnitude harder than learning Smalltalk. This is not to dismiss what you have said. On the contrary, it highlights what must be an enormous miss in how Pharo presents documentation on its landing page.
Rust the language is certainly more difficult than the Smalltalk language. The language isn't the issue.
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.
I don't think that's necessarily what the OP is saying. I agree with OP.
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.
This is a complex issue. In fact, you can work with Pharo in a Unix-like manner. Use an external editor to modify the source code and run the image without any GUI. However, by doing so, you lose the most interesting and enriching aspects of it. The Pharo team has worked hard to integrate better with the world outside the Pharo image. People still complain that it is not like anything else they know, but if it were, they would miss the opportunity to learn how to do things differently and possibly better. There is also a lot of excellent documentation available, especially the MOOC, but it requires newcomers to invest some time.
That totally makes sense. I'm not saying there aren't advantages to what is being done, but what is being done does add a level of complexity to it all.
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.
When it starts up there's a welcome-window, in it or like a few clicks down there's a tutorial called ProfStef that gives a quick tour through some data types and ways to execute code.
I think that's a pretty neat introduction to the very basic basics.
I had the same experience. Spent a couple of (vacation) weeks devoting 2-3 hours a day to Pharo and going through all of one of the books from the website (Pharo by example? can't really remember).
It's really one of those things that will die out on their own, because of the many layers and the little applicability (outside of playing the gimmicks).
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.