I went through the MOOC material and tried it out for a few small things. It inherited a lot of the unique Smalltalk features which make it sort of alienating to a modern programmer. For instance, all your code resides in an image file, and if you want a copy of your code the environment does some extra epicycles to copy it outside. The choice to make everything a message, including basic flow control takes some getting used to. As you just sort of hack your image to do what you want, it just sort of turns into a ball of mud. The paradigm they're going for is TDD for everything. Personally, I feel this is a big step backwards from most mainstream scripting languages adding on type annotations. It's not easy to use a simple text editor. You pretty much have to use their integrated environment.
Then, there were a few problems that were specific to Pharo. Pharo went through a couple different package systems and the different package systems don't necessarily have the same packages. Pharo has had major breaking changes in their GUI toolkit, so if you found a package that did exactly what you wanted and were able to install it, it just wouldn't work.
This is kinda the point of smalltalk. It's a radically different programming model _and_ paradigm than most C-derived languages. If you're looking for a language that feels comfortable to developers with a background in [insert widely-deployed language here], there are better options for you.
Smalltalk has been around for over 40 years, which makes it a contemporary to C. Just like FORTRAN or COBOL, there's a corpus of deployed code, and institutions that are invested in a maintained runtime, but that dosen't mean that you would necessarily want to use it for a new project today.
A lot of the great things about smalltalk, such as block syntax for anonymous functions, have been copied into many modern programming languages, and we probably wouldn't have them without smalltalk taking it's unconventional approach.
> The paradigm they're going for is TDD for everything. Personally, I feel this is a big step backwards from most mainstream scripting languages adding on type annotations.
So, the push to add types to JS, Python, Ruby and other dynamic languages is largely from developers accustomed to Java, C-Sharp, and other enterprisy languages who would probably rather not work in a dynamic language at all. Put another way, it's a concession of these languages to try and be everything for everyone. But statically typed complied languages do not provide an inherently better programming paradigm than dynamic programming. Smalltalk commits further and deeper to a live, dynamic programming experience. It's different, and I don't feel like saying that it fails to conform to expectations brought in from other, very different programming paradigms is a meaningful criticism of the language.
> So, the push to add types to JS, Python, Ruby and other dynamic languages is largely from developers accustomed to Java, C-Sharp, and other enterprisy languages ...
Nope, this is not true. I am personally pushing to add types to our Python codebase, and I have no love for "Java, C-Sharp and other enterprisy languages".
It's just that as the codebase grows, and especially as number of contributors grows, people start to make more mistakes. A rarely used code path, like an error handler, might fail in production because of wrong type or missing argument. We can require unit tests with 100% coverage, but this is very hard -- and typing linter finds you many more bugs per effort spent.
That does not mean that we should always specify every type in program explicitly, like Java does. Unspecified types are great for interactive exploration, or a quick hack. But as you move to production, don't understimate typecheckers -- they can help a lot.
> But statically typed complied languages do not provide an inherently better programming paradigm than dynamic programming.
For any large long lived project with multiple contributors, statically type analysis definitely adds value by eliminating an entire class of errors at compile time.
> the push to add types to JS, Python, Ruby and other dynamic languages is largely from developers accustomed to Java, C-Sharp, and other enterprisy languages who would probably rather not work in a dynamic language at all
I recall Guido van Rossum stating once, that he got convinced of the necessity for type annotations by JetBrains explaining to him how hard it was to provide good code completion. Not sure its the full answer, but back then I found it interesting as an example how lobbying can work.
(I feel rather indifferent on the type annotations for Python actually, I can see their usefulness, but also the shortcomings of retroactively introducing such a system into a dynamically typed language).
> a copy of your code the environment does some extra epicycles to copy it outside
Iceberg https://github.com/pharo-vcs/iceberg is the Git/etc. integration built into Pharo and works extremely well. You don't need to "file out" code if that's what you meant.
As a very long time occasional Smalltalk user (on my 1108 Lisp Machine, Commercial on early Mac, later Squeak, then Pharo), I agree with you, except that Pharo has nice git integration that I can recommend spending the time to set up.
Also, I used to create Squeak headless standalone applications - plenty of tutorial material for this.
Lisp used to get a similar bad rap, but SBCL has good app packaging available and the commercial LispWorks makes it easy to build small standalone apps.
> As you just sort of hack your image to do what you want, it just sort of turns into a ball of mud.
No, it doesn't just turn into a ball of mud all-by-itself.
As you said, we can export our app code and bake a new working image (vendor image + our app code — kind-of like a container, kind-of like a reproducible development process.)
Pharo and Smalltalk in general always remind me of that famous William Gibson quote: "The future is already here—It’s just not very evenly distributed".
If any Pharo folks are reading this, here's a small website feature request: Let me click on the images of this page to get full-resolution, un-cropped versions.
Pharo follows from Smalltalk, particularly through Squeak. It started off as a fork of Squeak and retains Smalltalk's syntax, but has gone its own way in terms of the capabilities it provides and rewriting portions.
I really appreciate that a blog post about a language update starts with a simple sentence to describe what the language actually is.
> Pharo is a pure object-oriented programming language and a powerful environment, focused on simplicity and immediate feedback.
Many times I land on announcements about Foo v3.0 that is super awesome and describes the diff from v2.5, with no mention whatsoever about what Foo actually is.
Congratulations to all the Pharo folks. It’s good to see a number of names in the contributors list that I still recognize. I really impressed that Pharo has maintained ground this long.
This coming June, it will be 10 years since I jumped out of the Smalltalk balloon, and dedicated myself to embracing polyglotism, right tool for right job, pragmatism, etc.
I miss the community. I miss many of the elegant aspects of Smalltalk. Maybe, since it’s release 10, and I’ve journeyed elsewhere for 10 years, I should give Pharo a spin. Any pointers for ye olde VisualWorks guru to get up to speed again?
Who's using Pharo in production? Every time Smalltalk comes up, it's almost like it's this Loch Ness monster that everyone claims to be enamored with but doesn't actually exist. I want to love Pharo so much, I just can't think of a single thing it would be useful for.
Why does knowing who else is using something have any impact on your ability to love it? Sounds like it's just a motivation problem perhaps?
For example, I make use of Plan 9 daily, and I don't really give a whip if anyone else thinks it's worth anything at all.
I also use Emacs lisp in pretty strange ways (automating workflows by cross-querying REST services in ways I used to do by hand). I've even demonstrated it for coworkers, and I think some of them may be using the same techniques, but I'm not sure, and I don't care. If they have questions about it, I'll answer them. If not, they can say "that guy's weird", and I'm totally fine with that.
Outnerd the nerds I say! Let your freak flag fly!
In all seriousness I encourage people to write some code. Play around! Share your experiences. It's good for you and everyone else to foster new ideas and be innovative. It's especially good if the technology in question is surrounded by a welcoming community. It provides an additional sense of belonging to something, and who knows you might just actually enjoy yourself!
You've got the first spark of curiosity, now you've just got to stoke the flames, or not!
>Why does knowing who else is using something have any impact on your ability to love it? Sounds like it's just a motivation problem perhaps?
Not making a value judgement. I agree that it doesn't need any more reason to exist than for its own sake. But I'm just genuinely curious what advantages Pharo has that make it useful in a professional setting.
Hacker News has become mainstream. Which means leet code grind with Java Python or JavaScript. The hackers are still here. But they are just a minority.
SmallTalk as a language is IMVHO terrible BUT it's strength came from it's concept, an user-programmable environment, that's matter so much.
SmallTalk was the language of first commercial desktop environments, modern desktops with keyboard, mouse, a similar form factor than today desktop, networking etc and those historical systems are still far more advanced than today's ones.
Personally I prefer Lisp as a base language, but in any case the concept is far more important than the rest. A thing humanity lost years ago and that need to recover ASAP.
I find preferences-wars a source of evil. Lisp is fine, not the subject here, tho.
Back to the subject, Smalltalk's syntax allows the most elegant expression of computer code similar to natural written language I've seen. And that at the lowest cognitive load to learn and read that the computer world provided so far.
I'm with you about raising the importance on concepts and that humanity needs to rescue its capacity for making that relevant again. I'm afraid Post-modernism is liquifying intelligence and is making everything regarding to intelligence to be harder to flourish.
PS:
We use a lot of camel case but please remember it's Smalltalk (instead of SmallTalk).
It has nothing to do with philosophical concepts and everything with business culture.
There are tools that facilitate expression, innovation and individual contribution. And there are tools that make it easier to scale and for programmers to be interchangeable.
These two are very hard to unify. There’s cross pollination but that’s about it.
Whether you’re in a top down hierarchical business model or in one that’s more open and people centric has a significant impact on which type of tools you’re using.
Smalltalk, Lisp and their descendants belong to the former category. They are immersive, expressive and incredibly dynamic and their communities are often pioneers. But this type of freedom comes at a cost that some do not want to pay.
> We use a lot of camel case but please remember it's Smalltalk (instead of SmallTalk).
Thanks, correction registered :-)
I agree about preferences-war, I generally tell my preference not to start flame but to give something for a positive discussion, witch means "how many in a community prefer $this more than $that and why" but less about the "similarity" with a natural language: in nature we use words as tags, so "objects" are natural, message passing is "natural" in the sense of collaboration between humans, but not really in the OOP sense. Also Smalltalk syntax to me does not look much similar to natural language.
The most similar language I found so far is Python, imperative programming is not so effective but is easier than functional for newcomers and it's syntax is very easy to read, IMVHO that's the reason of it's popularity especially compared with very similar (in targets) languages like Perl or Ruby.
Lisp is easy once you have learned a bit, and probably that's one part of why is not much popular, the rest, in common with Smalltalk is that both are designed for user programming, while "modern industry" want to lock users depriving them of any possible freedom and free usage of a desktop. In the past that was the IBM doctrine, thereafter the GAFAM doctrine: they all born out of Xerox tech, small part of it, wrapped in ways that put a product, a service at the center instead of the human. It's not only about liquefying intelligence but a mean to make hard doing certain things.
A stupid example: we have Wikidata, SPARQL is not that a great and digestible language but it's there, why the hell it's not normal just for a middle-school simple research query Wikidata form "a buffer" (in the Emacs sense of that) and see results in various forms we can manipulate to plot graphs etc at a level easy enough for a middle-school small student research? That's because IMVHO making easy doing so means users have power in their own hand, they can move not only in pre-defined and controllable paths but independently.
Why aggregators vs personal aggregators with RSS+Xerox style scoring? Again because aggregators might satisfy users demand BUT matching them to their hoster desire, for instance silencing or discrediting some news and enlarging others (try to see the recent polemics about Meta vs TikTok PR campaign) while a personal one can't be tweaked from remote so users might find their own path with their own ideas and tools.
Why "internet banking website" instead of a common standard API (like EU OpenBank, but open for all) with a desktop client? With it, users can have their transactions digitally-signed on their own desktop, having multiple banks and banking services in the same place, with the same UI etc without we have surveillance on crappy banking websites, crappy authentication, nothing in our hands etc.
All those things have a common ground: modern/classic software development is compartmentalized with any human layer religiously separated from the others, ancient programming languages are designed for a coherent unique environment without barriers.
Eh, it's rare that you find a language simple enough that its syntax fits on an index card, yet conceptually rich enough that you can build complex systems with it. This is a feat in and of itself that warrants admiration and examination.
r5rs was almost this, but it lacked any real facility for creating ADTs, like a class system, instead just giving you the rudiments (closures, functions), and expecting you to do the rest. Racket fixes this, but it's also much more complicated than both r5rs and Smalltalk.
I agree on the Lisp part, textual syntax is nice for human understanding but will one day be no longer necessary. If only they had made a cheap Lisp machine!
> textual syntax is nice for human understanding but will one day be no longer necessary
Can you elaborate your vision? What future you imaging in human-computer UI terms? Visual programming so far have well proved to be a failure, modern visual programming is even worse than past tentative (see how crappy are visual environment from RPA to NodeRed&c)... Vocal interfaces are also crappy... Even if we look at sci-fi movies the computer interfaces they show are ridiculously inefficient... Just see Star Trek as an example: vocal commands in emergency situations that demands multiple seconds while a direct hit on keys demands just few ms, the Borg with neural connections and visual+touch UIs in their ships etc. Oh that's sci-fi of course but that means that even artists have so far failed to imaging different means.
> If only they had made a cheap Lisp machine!
At that time was not possible in scale and industrial terms, similar to the far older Xerox workstations, it's possible now, but too many do not even know that original desktop model and MANY (very skilled PhDs included) have even issues imagining it... Just myself using Emacs/EXWM in a presentation I generally create an extraordinary WOW effect on techies who fail to understand what they see live on the screen/projector, how is that possible, and there is nothing extraordinary, just EXWM/org-mode normal usage. That's the real issue, in common with Smalltalk: people who can understand do not know, people who can push classic model again do not want it at all, it hurt they skyrocketing high businesses (and curiously old business were in relative terms more profitable for anyone, only they do not assure by any means the possibility do dominate the market since being knowledge-based anyone who happen to have developed something good can succeed), the large mass of the rest of humanity do not even know what happen yesterday so...
Rather misleading - and seemingly insulting to the people who created and use Smalltalk and Squeak - that it doesn't say "Smalltalk" (not to mention Squeak) anywhere on the front page.
They should really give credit where credit is due; growing the Smalltalk community seems like a better idea rather than pretending it's something else and implying that Smalltalk is somehow something bad that they need to hide.
Readit News
Then, there were a few problems that were specific to Pharo. Pharo went through a couple different package systems and the different package systems don't necessarily have the same packages. Pharo has had major breaking changes in their GUI toolkit, so if you found a package that did exactly what you wanted and were able to install it, it just wouldn't work.
Smalltalk has been around for over 40 years, which makes it a contemporary to C. Just like FORTRAN or COBOL, there's a corpus of deployed code, and institutions that are invested in a maintained runtime, but that dosen't mean that you would necessarily want to use it for a new project today.
A lot of the great things about smalltalk, such as block syntax for anonymous functions, have been copied into many modern programming languages, and we probably wouldn't have them without smalltalk taking it's unconventional approach.
> The paradigm they're going for is TDD for everything. Personally, I feel this is a big step backwards from most mainstream scripting languages adding on type annotations.
So, the push to add types to JS, Python, Ruby and other dynamic languages is largely from developers accustomed to Java, C-Sharp, and other enterprisy languages who would probably rather not work in a dynamic language at all. Put another way, it's a concession of these languages to try and be everything for everyone. But statically typed complied languages do not provide an inherently better programming paradigm than dynamic programming. Smalltalk commits further and deeper to a live, dynamic programming experience. It's different, and I don't feel like saying that it fails to conform to expectations brought in from other, very different programming paradigms is a meaningful criticism of the language.
Nope, this is not true. I am personally pushing to add types to our Python codebase, and I have no love for "Java, C-Sharp and other enterprisy languages".
It's just that as the codebase grows, and especially as number of contributors grows, people start to make more mistakes. A rarely used code path, like an error handler, might fail in production because of wrong type or missing argument. We can require unit tests with 100% coverage, but this is very hard -- and typing linter finds you many more bugs per effort spent.
That does not mean that we should always specify every type in program explicitly, like Java does. Unspecified types are great for interactive exploration, or a quick hack. But as you move to production, don't understimate typecheckers -- they can help a lot.
For any large long lived project with multiple contributors, statically type analysis definitely adds value by eliminating an entire class of errors at compile time.
I recall Guido van Rossum stating once, that he got convinced of the necessity for type annotations by JetBrains explaining to him how hard it was to provide good code completion. Not sure its the full answer, but back then I found it interesting as an example how lobbying can work.
(I feel rather indifferent on the type annotations for Python actually, I can see their usefulness, but also the shortcomings of retroactively introducing such a system into a dynamically typed language).
Iceberg https://github.com/pharo-vcs/iceberg is the Git/etc. integration built into Pharo and works extremely well. You don't need to "file out" code if that's what you meant.
Also, I used to create Squeak headless standalone applications - plenty of tutorial material for this.
Lisp used to get a similar bad rap, but SBCL has good app packaging available and the commercial LispWorks makes it easy to build small standalone apps.
Smalltalk facilitated Kent Beck's invention of TDD.
No, it doesn't just turn into a ball of mud all-by-itself.
As you said, we can export our app code and bake a new working image (vendor image + our app code — kind-of like a container, kind-of like a reproducible development process.)
Because it is a version of Smalltalk.
If any Pharo folks are reading this, here's a small website feature request: Let me click on the images of this page to get full-resolution, un-cropped versions.
It sounds a lot like Smalltalk though. Do you know of a similar page that highlights the differences between pharo and Smalltalk?
> Pharo is a pure object-oriented programming language and a powerful environment, focused on simplicity and immediate feedback.
Many times I land on announcements about Foo v3.0 that is super awesome and describes the diff from v2.5, with no mention whatsoever about what Foo actually is.
Thank you!
This coming June, it will be 10 years since I jumped out of the Smalltalk balloon, and dedicated myself to embracing polyglotism, right tool for right job, pragmatism, etc.
I miss the community. I miss many of the elegant aspects of Smalltalk. Maybe, since it’s release 10, and I’ve journeyed elsewhere for 10 years, I should give Pharo a spin. Any pointers for ye olde VisualWorks guru to get up to speed again?
Or minor contributions to be made?
For example, I make use of Plan 9 daily, and I don't really give a whip if anyone else thinks it's worth anything at all.
I also use Emacs lisp in pretty strange ways (automating workflows by cross-querying REST services in ways I used to do by hand). I've even demonstrated it for coworkers, and I think some of them may be using the same techniques, but I'm not sure, and I don't care. If they have questions about it, I'll answer them. If not, they can say "that guy's weird", and I'm totally fine with that.
Outnerd the nerds I say! Let your freak flag fly!
In all seriousness I encourage people to write some code. Play around! Share your experiences. It's good for you and everyone else to foster new ideas and be innovative. It's especially good if the technology in question is surrounded by a welcoming community. It provides an additional sense of belonging to something, and who knows you might just actually enjoy yourself!
You've got the first spark of curiosity, now you've just got to stoke the flames, or not!
It's easier to learn to love something if you see how other people love it.
Not making a value judgement. I agree that it doesn't need any more reason to exist than for its own sake. But I'm just genuinely curious what advantages Pharo has that make it useful in a professional setting.
Here you have may others using it in production: https://pharo.org/success.html
[1] https://www.telna.com
- How many developers are working on that codebase simultaneously?
- What is your workflow like? Do you have any sort of CI system? How does it work?
- How does your deployment works? Is it a single beefy machine or a fleet of smaller ones?
- What kind of network protocols do you use? Any code generation?
- How do you deal with errors -- are there equivalents of "coredumps" or "logs" in the Pharo world?
https://pharo.org/success.html
Have you wanted to love Pharo enough to install and use it?
SmallTalk was the language of first commercial desktop environments, modern desktops with keyboard, mouse, a similar form factor than today desktop, networking etc and those historical systems are still far more advanced than today's ones.
Personally I prefer Lisp as a base language, but in any case the concept is far more important than the rest. A thing humanity lost years ago and that need to recover ASAP.
Back to the subject, Smalltalk's syntax allows the most elegant expression of computer code similar to natural written language I've seen. And that at the lowest cognitive load to learn and read that the computer world provided so far.
I'm with you about raising the importance on concepts and that humanity needs to rescue its capacity for making that relevant again. I'm afraid Post-modernism is liquifying intelligence and is making everything regarding to intelligence to be harder to flourish.
PS:
We use a lot of camel case but please remember it's Smalltalk (instead of SmallTalk).
There are tools that facilitate expression, innovation and individual contribution. And there are tools that make it easier to scale and for programmers to be interchangeable.
These two are very hard to unify. There’s cross pollination but that’s about it.
Whether you’re in a top down hierarchical business model or in one that’s more open and people centric has a significant impact on which type of tools you’re using.
Smalltalk, Lisp and their descendants belong to the former category. They are immersive, expressive and incredibly dynamic and their communities are often pioneers. But this type of freedom comes at a cost that some do not want to pay.
Thanks, correction registered :-)
I agree about preferences-war, I generally tell my preference not to start flame but to give something for a positive discussion, witch means "how many in a community prefer $this more than $that and why" but less about the "similarity" with a natural language: in nature we use words as tags, so "objects" are natural, message passing is "natural" in the sense of collaboration between humans, but not really in the OOP sense. Also Smalltalk syntax to me does not look much similar to natural language.
The most similar language I found so far is Python, imperative programming is not so effective but is easier than functional for newcomers and it's syntax is very easy to read, IMVHO that's the reason of it's popularity especially compared with very similar (in targets) languages like Perl or Ruby.
Lisp is easy once you have learned a bit, and probably that's one part of why is not much popular, the rest, in common with Smalltalk is that both are designed for user programming, while "modern industry" want to lock users depriving them of any possible freedom and free usage of a desktop. In the past that was the IBM doctrine, thereafter the GAFAM doctrine: they all born out of Xerox tech, small part of it, wrapped in ways that put a product, a service at the center instead of the human. It's not only about liquefying intelligence but a mean to make hard doing certain things.
A stupid example: we have Wikidata, SPARQL is not that a great and digestible language but it's there, why the hell it's not normal just for a middle-school simple research query Wikidata form "a buffer" (in the Emacs sense of that) and see results in various forms we can manipulate to plot graphs etc at a level easy enough for a middle-school small student research? That's because IMVHO making easy doing so means users have power in their own hand, they can move not only in pre-defined and controllable paths but independently.
Why aggregators vs personal aggregators with RSS+Xerox style scoring? Again because aggregators might satisfy users demand BUT matching them to their hoster desire, for instance silencing or discrediting some news and enlarging others (try to see the recent polemics about Meta vs TikTok PR campaign) while a personal one can't be tweaked from remote so users might find their own path with their own ideas and tools.
Why "internet banking website" instead of a common standard API (like EU OpenBank, but open for all) with a desktop client? With it, users can have their transactions digitally-signed on their own desktop, having multiple banks and banking services in the same place, with the same UI etc without we have surveillance on crappy banking websites, crappy authentication, nothing in our hands etc.
All those things have a common ground: modern/classic software development is compartmentalized with any human layer religiously separated from the others, ancient programming languages are designed for a coherent unique environment without barriers.
Eh, it's rare that you find a language simple enough that its syntax fits on an index card, yet conceptually rich enough that you can build complex systems with it. This is a feat in and of itself that warrants admiration and examination.
r5rs was almost this, but it lacked any real facility for creating ADTs, like a class system, instead just giving you the rudiments (closures, functions), and expecting you to do the rest. Racket fixes this, but it's also much more complicated than both r5rs and Smalltalk.
I agree on the Lisp part, textual syntax is nice for human understanding but will one day be no longer necessary. If only they had made a cheap Lisp machine!
Can you elaborate your vision? What future you imaging in human-computer UI terms? Visual programming so far have well proved to be a failure, modern visual programming is even worse than past tentative (see how crappy are visual environment from RPA to NodeRed&c)... Vocal interfaces are also crappy... Even if we look at sci-fi movies the computer interfaces they show are ridiculously inefficient... Just see Star Trek as an example: vocal commands in emergency situations that demands multiple seconds while a direct hit on keys demands just few ms, the Borg with neural connections and visual+touch UIs in their ships etc. Oh that's sci-fi of course but that means that even artists have so far failed to imaging different means.
> If only they had made a cheap Lisp machine!
At that time was not possible in scale and industrial terms, similar to the far older Xerox workstations, it's possible now, but too many do not even know that original desktop model and MANY (very skilled PhDs included) have even issues imagining it... Just myself using Emacs/EXWM in a presentation I generally create an extraordinary WOW effect on techies who fail to understand what they see live on the screen/projector, how is that possible, and there is nothing extraordinary, just EXWM/org-mode normal usage. That's the real issue, in common with Smalltalk: people who can understand do not know, people who can push classic model again do not want it at all, it hurt they skyrocketing high businesses (and curiously old business were in relative terms more profitable for anyone, only they do not assure by any means the possibility do dominate the market since being knowledge-based anyone who happen to have developed something good can succeed), the large mass of the rest of humanity do not even know what happen yesterday so...
They should really give credit where credit is due; growing the Smalltalk community seems like a better idea rather than pretending it's something else and implying that Smalltalk is somehow something bad that they need to hide.