Hacker News new | past | comments | ask | show | jobs | submit login
Pharo MOOC (pharo.org)
240 points by brudgers on Apr 4, 2018 | hide | past | web | favorite | 107 comments

I've used Pharo, and, way back, programmed professionally in Cincom (then ParkPlace), IBM VisualAge, and whatever the Windows version of Smalltalk was called was called (Visual Smalltalk?). Also tooled-around a bit in Squeak.

All three of the professional environments were very good. When Pharo kicked off, it was supposed to have been people building a free Smalltalk you could use to build real world software, as opposed to the research-oriented Squeak community. They didn't stick to that path, tho.

As another post described, Pharo is a mess, and it doesn't get more reliable from release to release. It's too bad. The idea that any Smalltalk environment today is state-of-the-art is just misguided. I would rather use Intellij IDEA any day.

Smalltalk is still a beautiful thing, tho.

It is like fitness. One just hates it when it aches all over the place and then quits. Or keeps on moving through the pain/grind and grow a lot in all kinds of ways.

And saying that VA or VW give a better user experience when coding vs Pharo, I beg to differ.

Except the pain in pharo doesn't come from the difficulty of learning new things or self-improvement but from the buggy environment itself. Learning to save your work every 5 minutes because it might crash any time doesn't make you a better dev, it just lowers your standards.

From your "learning experience report"(Dec 2017) linked further down I see that two of your main gripes relate to Bloc and Iceberg(Git).

* Bloc is not a "Released" subsystem. While its development group report Bloc is stabilizing and encourage more people to start exercising it, Bloc is not on the Pharo 7 Release roadmap. Pharo 6 is current stable release.

* For a long long time, Monticello was Pharo's main source code control system. Responding to general criticism that Smalltalk sometimes lives in its own shoebox and doesn't interface well to "standard" systems, Pharo is spending significant effort on Iceberg to adopt Git as its main version control system (I don't know of any other Smalltalk that has a GUI Git tool). But Iceberg is quite a new subsystem with a Technical Preview release in Pharo 6.0. It was initially slow to draw new users from Monticello as many users were not familiar with git, so bugs remained that were only exposed with broader use. Last December I was trying Iceberg and also experienced crashes with it.

One thing to keep in mind is that Pharo's usually great stability is due to everything being implemented in itself on a garbage collected virtual machine, i.e. memory-violation errors eliminated. Iceberg makes use of the "libgit" external C library via FFI. While this aligns with Pharo's policy of not reinventing the wheel (another oft criticism of Smalltalk) but does allow memory errors that normally could never occur. So the Iceberg subsystem is not a good benchmark to judge the stability of the rest of Pharo.

btw, Lately I've found Iceberg stability quite improved and I started using it daily. Also, based on constructive feedback an improved GUI is planned.

* Around December there was also bug in the new Garbage Compactor related to the conversion of the VM from 32-bit to 64-bit. This is a complex system that took a while to identify, diagnose and correct.

Unfortunately I think you landed in a perfect storm. If the presenter was trying to show off the latest features I guess you got caught up on the bleeding edge of development. Part of the problem here is Pharo bleeding edge is usually quite stable (I use it daily), but we of the Pharo choir better placed to work around any hiccups in order to push Pharo forward. But these should not be exposed to newcomers and you don't have time to deal with them in a classroom setting. I'm sorry this damaged your impression of Pharo, but please understand how your broad statements damage Pharo in turn.

Come on, you are just throwing mud around for some reason I do not even want to know about.

It is hard to lose code with Pharo. I have always recovered everything 99.999% of the time.

You are happy with VW, fine with me. I cannot stand it.

The reason is Stéphane Ducasse is using his students as unpaid testers[0]. I can't see any other reason he'd make us use the latest technologies as you mentioned.

I also don't like the approach "let's write some code that passes tests and maybe works 80% of the time, and then release a few fixes every week for the next few months". Some of my classmates had to wait for 2 weeks just to get a working version of iceberg for the team project. And by working i mean it managed to clone the project, we kept getting "message sent to nil" and "object X does not understand message Y" errors for the rest of the semester and not just from iceberg. Any of those would be trivially caught in a static language.

Yes, there's a recovery feature. I found it slightly buggy too but it worked most of the time (and yes, i used it a few times). Still doesn't help when the whole image gets corrupted and pharo segfaults on startup.

[0] https://news.ycombinator.com/item?id=16757107

Martin, IIUC you are a student that suffered a class using bleeding edge features. I can understand why you are bitter, but you should not be so quick to disparage Mr Ducasse. Your faculty was his client, and it seems that circumstance was outside his control. From our mail list...

Stephane Ducasse wrote:

> I told them NOT to use github.

> I told them that Bloc was alpha. They got a large list of topics and could have picked another one.

> Now of course we should improve and they too.

Fair point, i assumed using iceberg was his idea, my apologies if it wasn't. Can't comment on the stability of bloc, other team-members did that part of the project.

OTOH, please note that iceberg was only the tip of the iceberg (i am a huge fan of the name), the IDE itself did crash many times and corrupted my image once. The formatter moved comments into other blocks which changed their meaning and combined with CTRL+Z it deleted code after cursor in some cases reproducibly.

One extra funny though harmless bug was that shift+click didn't select a range of items items in some listboxes. It selected just the new one but left the old one highlighted. I clicked a few items and sometimes it selected the whole range. When I released shift and clicked more items, it played back the clicks i made earlier and selected those items instead. We joked that smalltalk did not only invent OOP but also command queuing in strategy games. Yeah, it was mean but we couldn't imagine what code had to be behind the listboxes to cause this behavior.

So yeah, maybe someone else thought OOP students would make a good typechecker for iceberg and designed the class accordingly but what i think and say about pharo still stands.

I'm sure VA and VW are out of date today, but when I used them, did not break all the time. The libraries worked together. I'm sorry to say that has not been my experience with Pharo.

> As another post described, Pharo is a mess, and it doesn't get more reliable from release to release.

Can you share this post, please?

I guess he is referring to the criticisms by martin-t.

I chose Pharo for a project recently (http://github.com/studio/studio/). I am enjoying using it in production. The Glamorous Toolkit framework (Inspector and Spotter) is saving me a huge amount of work.

I see Pharo as two universes: the stable (now Pharo 6) and the development (now Pharo 7.) I work on the stable one and I don't concern myself at all with what is happening on the development one. The yearly release cycle of development-to-stable feels about right to me.

I have had to spend some time working out how to fit Pharo into my wider project build system, and how to store Smalltalk source code on Github as part of a larger repository such that you can handle merges etc. This made me curse a lot. It worked out fine in the end though.

I have been working on this for one year now and I haven't had problems with Pharo bugs or instability.

I couldn't even tell what the Glamorous Toolkit was or how to use it; what's the best resource for it? I remember checking out the website when it was released but couldn't make heads or tails of it.

You haven't been looking much then. http://gtoolkit.org

I see many comments talking about teaching objects with Pharo, we used to use it in the UNQ (a university in Argentina), now we use another Smalltalk flavour, because of the complexity of it. It's called CUIS, developed in Argentina too, the first days we use a framework that uses some similar to prototypes, so the students can start learning objects without the overhead of classes and inheritance. And then we switch to the classical class hierarchy way.

It's a nice tool! https://www.youtube.com/watch?v=e_e3_3MyTBY

Yes, Juan and community have done a good job with Cuis. Cuis is a fork of Squeak same as Pharo, and all three use the same OpenSmalltalk-VM. Both forks arose to deal with a large technical debt in different ways. Cuis has been paring back class sizes while Pharo has been focused on a full source-code only bootstrap from a null-Image (i.e. no carried over state in an Image, that is one of Smalltalk's typical criticisms), replacing old subsystems, as well as adding new features. I'd say Pharo is more ambitious and we are starting to see the payoffs for this.

btw, which was the CUIS prototype framework you used? There should be little reason it couldn't be made to run on Pharo.

The framework is called Denotative Objects.


Even if you are not going to develop any major apps in Smalltalk, its a language worth learning. Teaches you a lot about OO programming

I agree that it is a language worth understanding. However the OO model of Ruby is identical. Without the drawbacks of being an image based language. So I'd suggest learning that instead.

For those who don't know what I am talking about, there are several families of languages where the state of your program is kept within an image. The upside of this is that you can integrate everything together in a really neat way and build neat tooling with introspection. The downside is that you have just made what's going on not visible from the filesystem, and have to replace all of the tooling that you're used to. You know, things like your favorite editor, command line programs, source control...

If you switch languages regularly (which most developers do in my experience), being able to use your favorite toolset everywhere turns out to be more important than being able to build an ideal toolset for only one language.

> I agree that it is a language worth understanding. However the OO model of Ruby is identical....

I independently arrived at the same conclusion. The main problem with Pharo is the esoteric tooling; life is too short to struggle with tools.

That said, I consider Smalltalk, Objects and Design by Chamond Liu to be one of the best books I ever read on the subject of object oriented programming. Heartily recommended.

I guess it depends on the taste of the developer. I really enjoy seeing newcomers posting in the mail list saying that Pharo makes "programming fun again".

But Pharo is all about the deep integration of the tooling. Its what facilitates such a tight Code->Compile->Run->Debug cycle. It can take a while for the penny to drop. If you do a drive-by taste of Pharo you probably didn't get chance to really get into the flow.

Some say... "The only programming languages worth learning are those that change the way you think about programming." And Pharo/Smalltalk tooling does that.

Tooling appears exotical because you are not using it day in day out.

And I actually find things like Spotter, Code Rewriter, GTInspector and Calypso pretty neat.

IntelliJ is not simpler and is closed source. It is neat, true. We even use its icons in Pharo.

Tooling appears exotical because you are not using it day in day out.

And that's the problem. The tools are different. They require learning. And once learned, they are only useful for dealing with one language. And that is a language that nobody around me uses.

The result is a barrier to entry. A barrier to entry of a type that I'm not bothering with again unless I have a good reason to.

Furthermore the small size of the community means that I am unlikely to get to choose tools that fit me. I'll be stuck with whatever the personal preferences were of the people who wrote the tooling. Even if I like them, my neighbor probably won't.

You bring up IntelliJ. However I don't use IntelliJ. I prefer vi and command lines. The guy sitting across from me likes Visual Studio. I couldn't tell you how many other IDEs are in use by programmers in the same space as me. No single toolset is going to be to all of our tastes. And it doesn't matter with a filesystem based language, because we are each free to use whatever we want.

> I'll be stuck with whatever the personal preferences were of the people who wrote the tooling.

User experience is one area where Smalltalk seems like it could use some focus on. Compare the screenshot of the system browser on pharo.org compared to figure 17.1 (page 293, PDF page 315) of the "blue book":


Apparently that layout was perfected in 1980. Has anyone ever experimented with showing more than one method at a time in a window? And taking up less screen real estate with the class hierarchy? Seems ripe for some new thinking here.

I am also using Tmux and Vi an awful lot.

And working on a fuse thing that exposes my running image as a filesystem so that I can such tools as well.

But saying that the tools are different and you cannot be bothered to use them? Look, Visual Studio is a monster beast, with tons and tons of features, including Azure ones. It takes a serious while to master.

And vim also takes a serious while to use well. Especially when we use a couple of plugins.

An engineer knows the tools. Then a specialist masters them. The master makes them. Or changes them.

Pharo allows one to do that. Without strings attached.

I believe the point the parent is trying to make is that when you spend the time to learn Visual Studio, vim, etc. you can transfer that knowledge to multiple languages. With Pharo those tools are limited to, well, Pharo.

The benefits of learning a particular tool are essentially proportional to how often you use that tool. The greater flexibility of other tools such as vim means that the cost of learning it can be amortized over essentially as many projects as you wish. The costs for learning Pharo tooling are only spread over as many Pharo projects you do. If you don't believe you'll be doing all that much in Pharo, it makes it a fairly daunting proposition to invest that time.

> The downside is that you have just made what's going on not visible from the filesystem, and have to replace all of the tooling that you're used to. You know, things like your favorite editor, command line programs, source control...

While Pharo (and Squeak, etc.) have baked in editors and source control, Pharo has integrating with general tools as a design goal. It includes an integrated Git client and can load packages from or move them into a Git repository.

Per https://www.peteruhnak.com/blog/2016/07/25/how-to-use-git-an... as of 2 years ago Pharo did not have an established convenient way to integrate with git. Per https://github.com/pharo-vcs/iceberg the current best solution for that is still an experimental tool, so you have to be careful. Being able to integrate with other version control systems is still off in the future.

Integrating with general tools may be a design goal. Yet it clearly isn't fully there. A filesystem based language does better without even trying.

Not it doesn't.

Iceberg is breaking new ground compared o Kraken/SourceTree etc.

Pharo took the risk of integrating git support in the tools.

It takes a few iterations.

So what? Either one is a user or one is inventing new stuff. When was it you wrote a full wrapper for libgit? And made it available to any app? Yes, any Pharo app now has the ability to use libgit features. Awesome and opening quite some doors.

Pharo devs are not inventing new stuff, they're reimplementing existing stuff, poorly, in their favorite language because said language is incapable of interfacing with the existing mature tools.

Whoever designed the GUI also probably never used even git, or they couldn't stand their own tool. From the top of my head: 1) it shows all commits in a linear list (with broken unicode) completely ignoring branches 2) deletions are green and additions red.

Congratulations. You came up with a reason to do a whole bunch of work that you found fun. Work of a kind that is entirely unneeded in other languages. Do you want a cookie?

All developers are users of someone else's software and knowledge. I'm OK with that, and happy to not reinvent perfectly good wheels. You go ahead and enjoy wrapping libgit.

My preference is to understand how to use data to help businesses. For example a decade ago I gave a tutorial on A/B testing which resulted in multiple companies adding many millions to their own bottom line.

It is a big world. There is room for all kinds.

I am busy with serious size Hadoop clusters as well, using a gazillion of technologies (including some Pharo on YARN mind you).

Nobody forces one to use Pharo and I actually find it indeed useful to have an FFI binding to libgit.

Pharo has had git support for years with git filetree. There is no urgent need for a built in tool. Iceberg is an integrated tool which is not even yet released for the version of Pharo it is intended for (7).

The project is useful to test drive UFFI significantly. As such it is a really good test bed for all kinds 7of data structures and callbacks etc. Coupled with the 64 bit VM + image it is even more so.

I am in the Pharo ecosystem as a long play. Expedient solutions are plentiful. But they all lack this QWAN in Pharo that makes it enjoyable to me.

I am interested in understanding how things do work. Pharo allows me to do it in a way that suits me.

Given the count of "me" above, it is clear that I follow my own path and I couldn't care less about popularity.

Truth be told, I find it somewhat useful to have a harder to approach community. It keeps the signal to npise ratio at an acceptable level.

There is room for all kinds indeed.

Yes, I'd like a cookie. But not for libgit, but libstrophe. It was easier (and clean!) to bind with Pharo than with a lot of other technologies. The ability to pin objects is also very usable.

>I agree that it is a language worth understanding. However the OO model of Ruby is identical.

Smalltalk is much more than the OO model.

And yet if your goal is to learn about OO programming from the concepts of its OO model, then either language is good and Ruby is more convenient.

On the other hand if your intent is to learn about its collection classes, what MVC looked like in its original inspiration, and so on, then you should learn Smalltalk.

There is more to learn than any of us has time for. If you know what you hope to get out of learning something like X, then you should pick the most convenient X around to learn it.

Ruby the language, fails quite short of Smalltalk full graphical experience.

Well, it's not an IDE, so it's not fair to compare it to Pharo which is trying to be both a runtime environment and an IDE. If anything, it's an advantage that Ruby allows you to make choices about the development environment you use.

I think it's fair to compare the language+environment which is the only thing that practically matters. Smalltalk has a really nice IDE and fast VM. Ruby doesn't have a native IDE, but does well with things like Vim & Notepad++. Ruby has a lot more modules and Rails. I wouldn't consider Ruby to be very fast being one of the slowest popular languages out there.

Rubyists might know of Ruby books written by Avdi Grimm, who recorded his early experience with Pharo... https://www.youtube.com/watch?v=HOuZyOKa91o

I'd extend that by saying it teaches you what OO was meant to be.. It also shows you a lot of what is missing in modern environments. Imagine being able to run code and create any objects via a kind of command line and while any program is running be able to change it on the fly for experimentation/exploration purposes! I wish .net had something like this!

VS does have that functionality, although it was only added in VS 2015:


Previously there was the Immediate window but it is limited:


unfortunately, it's not really the same as with proper message passing/late binding like in smalltalk.

You could use C# dynamic objects to achieve late binding.

I'm not familiar with these. Are the properties and methods that dynamically add visible in the code editor?

It seems C# work by subclassing the DynamicObject class. What about dynamically extending all the other existing C# classes?

What if I subclassed a C# Queue as MyQueue and then while my days long simulation was running I wanted add an instance variable 'trackCount' to all existing MyQueue instances? In Pharo all you do is this...

Queue subclass: #MyQueue instanceVariableNames: ’trackCount’ classVariableNames: ’’ poolDictionaries: ’’ category: ’Example’

and program keeps running, this definition is updated in the editor.

of course you could also build a whole smalltalk environment in C# also, but that really is not the point.

Try a become: in C#

Gilad Bracha (co-author of the Java Language Specification) on "#become:" in Smalltalk (https://gbracha.blogspot.com.au/2009/07/miracle-of-become.ht...)

btw, see the section here on "Blub Paradox" (http://www.paulgraham.com/avg.html ) which means I'm not really competent to comment of C#'s dynamic objects.

Isn't Pharo a different language from Smalltalk?

That's sort of like asking if Scheme is a different language than Lisp.

Or maybe like asking if Racket is a different language than Scheme.

So the answer is "yes".

They are ok with evolving past the Smalltalk-80 standard. Think of it as a Smalltalk language + new things if they are beneficial. Cool project for sure.

Maybe; it's part of the OpenSmalltalk Initiative, and uses the same VM as Squeak, of which it started as a fork; whether it's a Smalltalk-descended language or a Smalltalk dialect is a matter of exactly where you draw the line.

It started out as a fork of Squeak; IDK how much it has diverged since then.

Don't know either, but the pharo MOOC I did a few years back only mentioned differences once or twice. I left with the feeling that beside a few, maybe syntax tweaks and new libs, it's 'same' enough.

Smalltalk teaches no OOP that cannot be learned by more modern languages, starting with Ruby (which is already pretty old itself). And at least, these other languages don't impose on you broken IDE's that crash all the time and corrupt your work.

I find little point in learning Smalltalk today, except maybe read a ten minute article to check out its odd syntax.

Ruby the language still doesn't have the development experience of 90's Smalltalk environments, not even JIT compilers that work half as fast as Smalltalk ones.

Pharo is great for doing Test driven development:

1. write a test

2. run the test

3. test fails; debugger pop up

4. implement/fix the method inside the debugger

5. repeat at 2 until the test succeed.

it's usual that a coding session is entirely done in the debugger which is like an interactive coding environment where absolutely everything is inspectable.

demo: https://www.youtube.com/watch?v=ymITEeAOtEA

Random off-topic feedback: the video is not correctly configured in Firefox (on MacOS). The pervasiveness of Chrome scares me sometimes.

It works here on firefox (linux).

Works for me on Firefox on macOS.

works fine for me using firefox on windows

I have been using Pharo since its 1.x releases and deployed commercial solutions using it.

Very stable. Quite powerful.

And it was/is a pleasure to work work with it.

One has to invest time and effort to master it. I would say that this is best suited to people who actually know what they are doing. Syntax is easy but frameworks are very advanced. So, do not go there without support.

I see comments that are not that kind to Pharo. I do to care to be honest. I do not think that Pharo is for the masses.

It has imperfections but nothing is at the core. And things are moving forward very well.

As a Pharo consortium member I vote with cash and usage.

"Pharo is a pure object-oriented programming language in the tradition of Smalltalk. It offers a unique developing experience in constant interaction with live objects. ... When programming in Pharo, you are immersed in a world of live objects. You have immediate feedback at any moment of your development on objects representing web applications, code itself, graphics, network."

Video lectures are in French.

They are dubbed in English as well.

Looking at slides while reading subtitles is really hard.

Smalltalk was the first language I loved. It was great to write, but I had difficulty understanding the structure of other's code. Even with that great integrated debugger, I couldn't figure out how Morphic actually worked.

These days for graphical programming, I prefer C with nuklear (https://github.com/vurtun/nuklear) over smalltalk.

Many people find that about the depths of Morphic. It has high technical which Pharo is addressing by creating a new system Bloc (its getting close, but not there yet). Then Morphic will be deprecated.

Is anyone else having trouble viewing this on their phone?

Oh yeah, it goes really slow and scrolling is broken and really off center. I gave up.

Works well for me on Firefox/Android besides the video making the page wider than the screen width. What trouble are you having? Which browser/OS?

Came to comments to see what this even is.

This is kind of an offtopic question, but regardless: Is there any application written in smalltalk in the debian repository? (or any other linux distro)

The only people I've heard of using Smalltalk at all other than in dogfood situations are people using Gemstone.


JPMorgan have a fairly serious Smalltalk app http://www.cincom.com/pdf/CS040819-1.pdf

However, only one. Make of that what you will.

They only have on app because Smalltalk if agile enough they build everything they need into it as the need arises - and this has been maintained over many years.

Gemstone is not "using" Smalltalk. Gemstone "is-a" Smalltalk.

Here are commercial companies that believe in Pharo (in the money on the table way of measuring belief)


Interesting. So am I right in assuming there are:

    - 9 bronze level (1k Euro/year)
    - 5 silver level (2k Euro/year)
    - 11 gold level (4k Euro/year)
    - 5 platinum level (8k Euro/year)
...members of the consortium (based on the color of the surround on the member label/icon)? So that would be ~103,000 Euro per year? Or is that signifying a one-time contribution (vs. recurring annual)? It doesn't look like there has been a consortium report published since 2015:


...any ideas what that means? (i.e. they stopped publishing them for privacy reasons, the consortium no longer has meetings, the consortium is no longer active, etc.?) Any ideas on what projects they are currently funding, and how many man-hours of programmer time are being purchased for Pharo in 2018?

Its a recurring fee. Of course, its dependent on members feeling they are getting value for money and continuing each year. The platinum level was only recently created.

I don't know what it means that there is not later reports. The consortium is definitely active. It arose because open source software is about people scratching an itch, and often the focus is on the fun stuff and not on the boring, difficult, dirty engineering required to make a product reliable and successful (e.g. operating a CI infrastructure). Pharo arose out of INRIA[1], one of France's publicly funded national research institutes. But their mission and governance structure is not suited to managing non-research engineers dedicated to working on Pharo. So InriaSoft[2] was created to fork off its successful software into consortiums funding pure engineering work on the software as an ongoing concern. At the moment the consortium has one full-time engineer, but hope to get another in the next couple of years if the consortium continues the current growth rate.

AFAIK (I am not directly involved), the main efforts decided by consortium members were:

* Stabilizing 32-bit to 64-bit conversion for Pharo, utilizing and contributing to the OpenSmalltalk-VM project.

* Stablizing Iceberg as our Git/GUI interface

* Maintaining CI infrastructure

btw, There is also the Pharo Association with 82 individual members. [3]

[1] https://www.inria.fr/en/institute/inria-in-brief/inria-in-a-... [2] https://www.inria.fr/en/news/news-from-inria/launch-of-inria... [3] https://association.pharo.org/

I know of a number of smaller business that are "as a service" that are built using Smalltalk.

Way back in the day, "DabbleDB" was written in Smalltalk. (It was a Zenkit/Airtable type web app.)

If I remember right, they had a separate image per customer and it took a moment to bring up the VM if hadn't been to the site in a while.

Sadly they got acqu-hired by twitter - and judging by some (not bad, just in lack of enthusiasm) comments, I got a sense that they sold dabbledb at peak technical/architectural debt...

It's a bit sad, I appeared to be a Google sheets meets office 365 flows on steroids before either was any good:


(i think that's from 2006 or so, archive.org has more info, but it's a bit painful to navigate on mobile)

Avi Bryant comments on hn from time to time:


As I understand it, each customer got an image/vm - and data was just stored as Smalltalk objects. It'd been interesting to see where they might have gone if they coupled the dabbledb front end with gemstone/s.

Gemstone provides a database. There are very large Smalltalk based applications that run using Gemstone as the backing database[1] . These applications are, for the most part, very large in-house applications that don't have much external visibility.

[1] http://seaside.gemtalksystems.com/docs/OOCL_SuccessStory.pdf

DrGeo is a geometry package for education.


MOOSE, which is some sort of code analysis tool:


I've never been able to make heads or tails of it, but it's kind of an architect-level tool and I'm just a lowly engineer.

The first one that comes to mind is the scratch package[1]. The entire scratch language, as far as I know, runs on top of squeak

[1] https://packages.ubuntu.com/source/trusty/scratch

Scratch was rewritten in JavaScript a few years back, AFAIK.

It was rewritten in Flash and now is being rewritten in Javascript. An independent project created an extended Scratch clone in Javascript called Snap!.

> It is very easy to learn...

> This Mooc is demanding but rewarding...

So the language is easy to learn and yet the course to learn it is demanding? Interesting logic...

Nevertheless, probably a good exercise for anybody who wants to learn what real Object Orientation is about and who didn't learn Smalltalk yet.

The language itself is simple[1] but the environment and tools aren't. Smalltalk is a world in itself which is both its strength and weakness.


I am well aware of that as I had my own trouble learning Smalltalk. Yet in hindsight I like the clean design of the language.

Nevertheless, I find the argument on their website kinda odd and a bit confusing. I mean, I see a lot of Smalltalk advocates claiming the language is so simple to learn and at the same time I see a lot of programmers having trouble learning it.

Maybe it is just wrong to call it 'very easy to learn' just because the syntax is simple.

The difficulty for me isn't the syntax, so much as not knowing how to use the tools. Examples are extreme like other niche languages. You get either hello world or writing a web server. I'd like to see someone build a YouTube channel with a lot of very small applications that show adding methods, classes,debugging, and deployment.

I don't know about Pharo, but I have seen very few IDEs which make it as easy as Smalltalk environments (e.g. VisualWorks) to do what you asked for as they provide you with GUI a for all that stuff. Pharo is probably no different.

I think the first important step, is to understand the different columns of the 'System Browser'. From a quick search that video playlist might help you:


I think non-programmers probably learn Smalltalk easier, assuming its natural. Long time programmers maybe have the frustration of unlearning habits.

"The only languages worth learning are those that change the way you think about programming."

Dabbling is easy.

Doing serious work is demanding.

But so is serious work in any environment.

Some videos don't even have english subtitles, eg 2.1 Understanding Messages :(

I had the "pleasure" of attending an OOP course at uni taught by Stéphane Ducasse. I didn't learn much OOP but i learned that pharo is an utter piece of garbage.

The IDE randomly crashes, corrupts images (all your work is in the persistent image) and randomly ignores clicks making it insanely frustrating to use. Git integration is "WIP" which means it sometimes silently deletes files or you just don't get it to work at all. Branches are not implemented, glhf resolving conflicts on a team project. Oh, and it saves your passwords in plain text.

Error messages will keep opening until you kill the "IDE" and undo will sometimes delete half your code with no way back (maybe that's why you're supposed to keep methods small?). It's a bit ironic that Mr. Ducasse calls himself an "expert on software quality".

Here's our final project, the weekly reports document our "learning" experience: https://gitlab.fit.cvut.cz/taibrmar/sokoban-using-bloc

Most students had similar feelings and the response to the course was overwhelmingly negative.

On your log you wrote, about the bugs you found, "no, i am not gonna bother reporting it, i am a user, not a TestCase" - Maybe that's why Pharo is so buggy?

If he wants to use our class as a typechecker, so be it, i am not gonna be part of it. (I briefly considered reporting them, but the HTTP-only login on their bug tracker turned me off)

From what I read on your project, it was quite daring to expose you to Bloc and Iceberg and the latest Pharo.

I wouldn't have.

Because these things are still in flux.

These things are interesting and are the way forward. But not ready for end users.

But this has exposed you to the realities of creating new things: it is not as clean as one would want nor are users that cool when facing them. In a unusual environment like Pharo, it gives a kind of blurring effect since a user has a hard time distinguishing between solid ground and treacherous new terrain.

I would advise you to look back at Bloc and Iceberg when Pharo 7 is released.

The occasionnal freeze of the environment is indeed a pain and a new user would cringe more than once. I actually have a REPL server running in my images to restart the UI when such stuff occurs. Not the realm of a newcomer for sure.

Pharo is great for my uses. It is not the best tool for everything, granted. But when dealing with complex domains, I haven't found anything close.

I'm double posting since I think its important to rebut with some background around this criticism. I can understand being bitter from bleeding edge subsystems being used for a class, but the content seems to have been decided by the faculty. From our mail list...

Stephane Ducasse wrote:

> I told them NOT to use github.

> I told them that Bloc was alpha. They got a large list of topics and could have picked another one.

> Now of course we should improve and they too.

This is not saying that everything in Pharo is perfect, but in future could you please frame your criticism to indicate your pain with Pharo was with alpha features.

Thanks for putting this out there. I found some weird things as well when using it, but just figured it was me. I was hoping your notes were from 2014, but it looks like you just went through all this.

Another problem with Pharo is the confusion with Bloc, Morphic, and Spec. With C# you have WinForms and that is pretty simple and Java has Swing. With Pharo, I can't seem to find a decent way to build a GUI. Is Spec supposed to replace Morphic?

In C# you have Winforms, WPF versions x,y, z.... and now UWA stuff.

And with Xamarin, a slew of other ways.

Not that less confusing.

It is actually documented though.

What about other Smalltalks? Some are used in industry, so probably should be more reliable.

From what I've gathered, Cincom is really good but very expensive.

There are a variety of proprietary language vendors with great products (Cincom Smalltalk, Dyalog APL, Wolfram language that is part of Mathematica), but it is a weird sale in the modern age. Why use a better tool if you have to pay for it and your entire business's IP is tied to another company pulling the strings. Even if they promise their tools are 10x more productive, is the risk acceptable?

The entry log from 2017-12-27 is appalling: one true namespace to rule them all and wreak havoc!

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact