Smalltalk is fun, but after having programmed with it for a year (Pharo only), I don't fully agree with the hype. And in certain cases, I feel the hype is under

Smalltalk is fun, but after having programmed with it for a year (Pharo only), I don't fully agree with the hype. And in certain cases, I feel the hype is undersold. But I'd love a bit more nuance. In my opinion, if you really want to convince the hardcore crowd on anything: nuance as best you can so people have an accurate sense of what they're getting into. I can talk a lot more about Smalltalk, but this comment got big enough as it is. I think in certain cases it can definitely be a secret weapon. > The syntax is ridiculously simple. It can be learned in its entirety within 15 minutes! Right, and then you learn that things like branches, loops and similar things are method calls. So it's not just the syntax you need to learn, the included libraries have things like: ifTrue:, ifTrue:ifFalse:, ifFalse:. There is also ifNil: and ifNotNil:. And IMO there are too many ways to do things. In order to be able to program, you need to learn these things as well. > The second major benefit is Smalltalk’s live coding capability The following issues are not all REPL issues but this quote made me think of the issues that I've encountered. There have been two instances where it wasn't fully live. For example, when I played with Roassal, I couldn't single step the animation through (whereas in an old Smalltalk demo this actually is possible). Or in seaside: the moment where a dynamic variable can't be evaluated properly because it spawns a different process internally and doesn't give the same value as the original process. The only way to fix that is to create a temporary variable and inspect that variable. It's an okay workaround, but the live coding ability or that seamless feeling of you can evaluate anything everywhere and debug it (with debuggers in debuggers in debuggers in...), yea... not always. The moments where it's possible (95% of the time) it is indeed magical. Also, why can't debuggers time travel? Like, is that too much to ask for a language that prides itself on being image-based / live everything / debug everything? I know people have worked on it, but I find it odd that it doesn't exist yet in the actual language. It must not be easy to make, but then again: many things of Pharo/Smalltalk have not been easy. This means it's a matter of priority. It should be higher. > The third major benefit is Smalltalk’s purity, clarity, and consistency in its object-oriented model. Smalltalk is the easiest object-oriented language for this reason, far surpassing C++, C#, Java, Python, and Ruby. Oh is it? I'd agree it is. But please stay objective though. Many things are played up as objects by the VM, but they aren't internally objects! I wouldn't know examples as I don't know the internals well enough, but I've talked to people that did on the Pharo Days. They told me. When you look in kernel code, there are pragma's just below the method signatures that betray this. > Smalltalk’s object-oriented nature makes it supremely maintainable and scalable without the headaches imposed by other object-oriented languages. It does, in my experience. > The fourth major benefit is Smalltalk’s system image. The image is a snapshot of an application’s total execution environment. It allows you to save the execution state of your program and to resume execution later on at your convenience. This is terribly handy. Well, be sure to back it up. It can also randomly crash. Text doesn't crash (though your text editor might. Hello VS Code ;-) ). The snapshot is amazing though. Going down the callstack and having every variable live, where I can interrogat- I mean interact with it. It's also awesome to put the debugger open live and just rewrite a method, replay the method and bam it works, debugger never closed. Can other languages do this? Probably. However, in Pharo this stuff is a first class citizen and you can feel it in the quickness of things (when it works that is, I already gave a few examples where it doesn't). > Smalltalk’s image also makes software deployment a breeze. You never have to worry about installing and configuring the numerous software components (like libraries and frameworks) that constitute your application in production. Well, for my scraper projects? Yes! True. For deploying a scalable web application? As far as I understand it: you have two options. You spin up hundreds of Smalltalk images that are ready to serve requests (yikes!). Or you use GemStone, which is another Smalltalk with an object-oriented DB designed for scalability. Smalltalks are mostly interoperable, until... they aren't! :D So there's a lot of glue code for the second option. Though, I'll say this: for creating hackable games (that you can just live program and alter) and personal scrapers... Yea, deployment is amazing. > For data science, you have tools like PolyMath, Roassal, and Moose. For machine learning, you can use TensorFlow and Keras. Don't forget: https://github.com/pharo-ai https://github.com/pharo-ai :D ------ The cool stuff that isn't talked about enough. Programming in Pharo makes me look different at software. It makes me more critical of GUIs of text editors and makes me look more critical at file-oriented programming. I'm a JavaScript fan too, but I find it odd that the Chrome debugger doesn't offer text-editing out of the box. It should! You can somehow make it happen? Why not make it happen out of the box. If Pharo can, why not a big well-funded thing like Chrome? I also like how Stackoverflow almost has no answers, so I need to think more deeply about my own answers. It molds me more into being an actual software engineer rather than a "call the function of this library please." Also, you sometimes get confronted with the VM, so your "stack-depth" is deeper than most web dev as you'll inadvertently pickup some VM things, which is basically computer architecture stuff. In short, Pharo cares more about cognitive ergonomy for the programmer. Other languages don't seem to do that, they seem to outsource that to tool makers. It's Apple vs any other PC (tight integration vs making something extensible). Both approaches are valid, but since the tightly integrated perspective is underrepresented in the programming realm, I'd love to see more attention to something such as Pharo or similar projects.