I started a new job in Smalltalk one year ago without any previous experience with the language (background in Scheme, a bit of Common Lisp / Clojure, C, C++, Java, Python, Haskell and a couple of other languages). I had three pair programming sessions in the beginning and that was it, it took me one month to get a grasp of the codebase I have to maintain/develop further. The application is huge, but the tooling and discoverability of the programming environment (including best debugging experience I've ever seen) made it super easy to dive into the system and learn everything practically by myself. This and the fact that everything follows the same basic design principles (objects all the way down) make it a perfect match for solving complex problems.
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!
I used to dislike OOP and favor functional programming languages, until I started working with Smalltalk. I guess the fact that blocks are closures and also first-class objects make up the difference somehow. I learned that programming paradigm is not the main factor I appreciate in a language, but also the elegant/coherent design, simplicity, liveness of the programming environment etc.
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.
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).
Yes last time I checked they had their own versioning system as well... it's one thing to learn a language but having to learn a whole new set of tools put me off in the end. I guess I can see the argument that the Smalltalk files are not plain text but rather images (or something), but having to basically download a second OS within the OS just to write Hello World was off putting. I realise that that's also can make Smalltalk so powerful, at least in principle.
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.
That's fine, I understand that a lot of my criticisms are arguably actually advantages, but after doing the MOOC about 8 years ago I just couldn't stick with it. Fun though, and a great way to really learn OOP at the time when I was just starting out programming.
Funnily enough, I'd compare the image and versioning differences to managing Postgres rather than non-image based languages.
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
Without ever practically using this system, my first impression is that this is how mech operating systems would have to be.
At a certain complexity of vehicle, you would need all of: manufacturer base features/diagnostics, safe-mode control, an open market of source code to add in, pilot preferences, and then real nerd stuff where you customize in your own routines. All the while being able to explore a live running system as it is running without having to trust closed binary only software.
Of course the world we live in would never go this way, proprietary unknowable, pre-government hacked, unrepairable trash it is for us.
I think Pharo still shines in open-source desktop applications. If I'd ever make a desktop application it'd be in Pharo as I'd want to encourage people hacking on it without ever committing it to git (if they don't want to) and have their own unique version of it.
Cuis [1] is a simplified fork of Squeak, trying to make it more closely resemble the original Smalltalk-80 (while using a custom version of Morphic). Squeak itself initially tried to not be bound by Smalltalk-80 heritage. Now, it focuses on preserving of the experiments that Alan Kay, Dan Ingalls, and others did, being very conservative in this regard. Pharo forked to have a system that can actually evolve.
Pharo should generally work on Wayland, so there will be more things going on, probably.
+Traits, +Slots, different class definition syntax and its processing, different file API, full block closures, different source file syntax, ByteArray literals, different comments syntax, many differences in the standard and UI library, etc.
No, Pharo is not Smalltalk-80.
I think incompatible Smalltalk implementations were one of the bigger barriers to Smalltalk adoption. In contrast, Java standard libraries have been a huge benefit.
You want cuis smalltalk. It's a heavily-simplified smalltalk (like pharo, it was also forked from squeak), with a redesigned morphic system - which is ENTIRELY vector graphics based (plus a few other niceties).
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.
I wanted to try it out, but I couldn't change the directories in pharo launcher to anything other than ~/Pharo.
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.
First, congrats to the Pharo team, I mean they do a lot of work.
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.
> 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.
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.
https://github.com/smarr/RoarVM is the main thing that comes up when trying to learn about this, and it hasn't been touched in over 10 years. I have also seen people working on spawning child VMs to handle parallelism, though unfortunately I don't have links to those discussions immediately at hand. It seems like perhaps an unnecessarily heavyweight approach, too, not a canonical solution that you would want to use in production.
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.
That feels very limiting. It's one thing to have a program run only on one core, but you're supposed to have your entire dev environment, including editor and debugger inside the VM. Won't that end up with the env freezing on compute heavy tasks?
Right, is the N (OS threads) == 1 in this case? It's a specific, technical way of asking if it can run parallel workloads across modern multi-core CPUs.
It seems too research-oriented programming IDE+language, where there is not a big market compared to other areas.
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.
Why would that be hard? Once you're fluent in it development in Pharo is very, very fast, you can build a GUI application while a prospect or customer is watching and supplying inputs about what they need.
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.
>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.
Does Pharo have a user base comparable to other programming environments?
If Pharo were really used in large-scale commercial and industrial applications, it would be as popular as Python, Java or C++. And it is far from it.
I repeat, "Pharo is very, very fast, you can build a GUI application..." is not something that is sells today, and if it were so competitively, companies would use Pharo instead of Flutter, Swift, etc. and on a large scale.
To me that reads like gibberish. Common Lisp is used in large-scale commercial and industrial applications, why isn't it "as popular as" Java?
Pharo and other Smalltalks are used in ERP and similar systems. It's attractive if your business requirements change a lot and you either don't want or can't afford to employ a legion of Java developers. You could write to https://www.cincomsmalltalk.com/main/products/visualworks/ and ask why those logos are at the bottom of that page, now that Smalltalk isn't as popular as it would be if it was any good.
As a CTO I don't really care whether a programming language and toolchain "sells today" or whether it is "competitive" in some general, presumably universal, sense. I want tooling that fits the problem domain really well, and sometimes niche tools outperform general tools by a large margin for certain problems. They might require fewer developers, allow faster development or better scaling than e.g. Java.
Perhaps you could be more charitable in your reading.
> Common Lisp is used in large-scale commercial and industrial applications, why isn't it "as popular as" Java?
Because those large-scale commercial and industrial Smalltalk applications are mid-1990s business-critical legacy systems!
"Over six months in 1996, Smalltalk’s place in the market changed from the enterprise darling COBOL replacement to yet another disappointing tool with a long tail of deployed applications that needed to be maintained.
…
the commercial Smalltalk vendors were unable to counter the Java hype cycle and development of new Smalltalk-based enterprise applications stopped.
"
Many comments in the vein that pharo is weird and different from what they're used to. I'd say programming is such a young field programmers should dedicate time to try out the weird stuff that they aren't used to, opportunities to rewire your brain for better.
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
Smalltalk had a moment at the transition from green screen to PC's, fumbled the everything is a string internet, and never showed-up for the multicore + GPU party.
Meanwhile the nasty statically type checked languages lowered the pain level with non-nullable and type inference for local vars.
As-already stated in this discussion RoarVM "hasn't been touched in over 10 years". This discussion is about the Pharo 12 release and supposedly RoarVM is "compatible with Squeak 4.1 and Pharo 1.2 ".
They removed a lot of the capabilities of Squeak and most of the nice legacy code included for educational and historical purposes, and neutered the object inspection tools. I understand that Pharo is no longer Squeak and the whole idea was to simply take Squeak and change not just the UI but the actual language. But I'm just a Squeak person.
actually, from pharo's perspective the goal was to remove bloat, things that didn't help active new development. as a result pharo images were smaller, and didn't have to support lots of old legacy code or objects.
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.
Yes, very different is part of less pragmatic IMHO.
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.
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/
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.
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.
Wasn't that George W. Bush?
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.
And I still to this day enjoy combining your #3 (emacs) with your #5 (MOO) via e.g. https://github.com/toddsundsted/rmoo
You might appreciate my project: https://github.com/rdaum/moor
(Though it's in a bit of a slow period because of Real Life(tm))
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.
If you’re looking for a good real life code base that is not the bare Pharo, you can check out Glamorous Toolkit: https://gtoolkit.com//
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).
https://books.pharo.org/pharo-by-example9/
https://github.com/Cuis-Smalltalk/Learning-Cuis/blob/master/...
"The Cuis Book"
https://cuis-smalltalk.github.io/TheCuisBook/
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 :)
https://pharo.org/success/
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.
Why? Are you making a lot of changes that conflict with the distro?
"Guideline 120 Avoid modifying the existing behavior of base system classes." :-)
1996 Smalltalk with Style page 95
https://rmod-files.lille.inria.fr/FreeBooks/WithStyle/Smallt...
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/...
That's your decision to make and I have no reason to quarrel.
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.
Also there's lots of free books at https://books.pharo.org/
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.
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).
Pharo Syntax in a Nutshell:
http://rmod-pharo-mooc.lille.inria.fr/MOOC/PharoMOOC/Week1/C...
https://en.wikipedia.org/wiki/Pharo
>"Pharo is an open source, cross-platform implementation of the classic Smalltalk-80 programming language and runtime.[3]"
https://en.wikipedia.org/wiki/Smalltalk
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.
Using git with Pharo: https://books.pharo.org/booklet-ManageCode/pdf/2020-05-12-Ma...
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:
pharo is the VM.Pharo10-SNAPSHOT-64bit-502addc.image is the image.
hello.st is a plain text file.
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...
- docker image - vscode preibstalled - and everything used the same programming language.
Is a pretty good overview how the environment works.
Pharo should generally work on Wayland, so there will be more things going on, probably.
[1] https://cuis.st/
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.
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.
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.
https://en.wikipedia.org/wiki/Green_thread
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.
Does Pharo have a user base comparable to other programming environments?
If Pharo were really used in large-scale commercial and industrial applications, it would be as popular as Python, Java or C++. And it is far from it.
I repeat, "Pharo is very, very fast, you can build a GUI application..." is not something that is sells today, and if it were so competitively, companies would use Pharo instead of Flutter, Swift, etc. and on a large scale.
Pharo and other Smalltalks are used in ERP and similar systems. It's attractive if your business requirements change a lot and you either don't want or can't afford to employ a legion of Java developers. You could write to https://www.cincomsmalltalk.com/main/products/visualworks/ and ask why those logos are at the bottom of that page, now that Smalltalk isn't as popular as it would be if it was any good.
As a CTO I don't really care whether a programming language and toolchain "sells today" or whether it is "competitive" in some general, presumably universal, sense. I want tooling that fits the problem domain really well, and sometimes niche tools outperform general tools by a large margin for certain problems. They might require fewer developers, allow faster development or better scaling than e.g. Java.
Perhaps you could be more charitable in your reading.
> Common Lisp is used in large-scale commercial and industrial applications, why isn't it "as popular as" Java?
Because those large-scale commercial and industrial Smalltalk applications are mid-1990s business-critical legacy systems!
"Over six months in 1996, Smalltalk’s place in the market changed from the enterprise darling COBOL replacement to yet another disappointing tool with a long tail of deployed applications that needed to be maintained. … the commercial Smalltalk vendors were unable to counter the Java hype cycle and development of new Smalltalk-based enterprise applications stopped. "
https://wirfs-brock.com/allen/posts/914
You're answering a question I didn't ask, and quotes an article of dubious relevance.
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.
For highly parallel general-purpose computations? Tell us more!
https://chapel-lang.org/docs/technotes/gpu.html
As-already stated in this discussion RoarVM "hasn't been touched in over 10 years". This discussion is about the Pharo 12 release and supposedly RoarVM is "compatible with Squeak 4.1 and Pharo 1.2 ".
https://github.com/smarr/RoarVM
For example: "Optimizing Machine Learning Performance at Netsuite with GraalVM and NVIDIA GPUs"
https://medium.com/graalvm/optimizing-machine-learning-perfo...
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.
https://news.ycombinator.com/newsguidelines.html
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.