One of the things to appreciate with Pharo Smalltalk is a code snippet isn't a code snippet.
Pharo is not a filesystem/.txt coding environment.
It's a VM runtime with every single element is indexed by the class/traits hierarchy. And then the same code draws the GUI.
OP didn't just write a code snippet.
They wrote a method, tested it in an already launched dynamic runtime.
And deployed it into a desktop app in front of you.
Forget Jenkins, Docker-Compose or Make, their deploy tool was copy/paste.
It's truly a pity that desktop based applications are not popular in the current age, and phones are locked down.
Smalltalk remains truly unparalleled at producing local apps. 30 years after its heyday, SwiftUI is still a shadow of what Smalltalk can do.
From 2016 to 2018 I worked on a complex case management application that was implemented in Smalltalk. It ran on Visual Smalltalk Enterprise (last updated in 1999! But the app was first put into production in 1996...) which is really quite crufty compared to Pharo, but the development experience still blew me away. The Smalltalk way of working takes some getting used to, but once I got into the swing of it, it was the the smoothest development process I've had: you log into the app and do your stuff. Poke some bugs, try to reproduce them, maybe find some completely unrelated error, and whenever you update the code you just save the methods and pick right back up from where you left off.
My favorite example: as the game is easily extendable.
Very nice! Thanks for sharing!
It's gonna be part of a benchmark for how long until "engineers" realize they're stupid.
Engineers are still just humans which means they're susceptible to marketing same as any other human. Much of the evolution of popular programming languages is just marketing, most obviously in the case of Javascript.
Partly true, partly not true. It's somehow sad to see educated people falling for these tricks. But actually my issue is not about people being diverted by market dynamics.. i can empathize with that. It's the non recognition, non interest when presented with these artefacts. No curiosity, no reading grid to analyze systems or ideas.. shallow reflex criticism .. super odd to me.
"Image-based" is typically how this is described, e.g. https://wiki.c2.com/?ImageBasedLanguage
Pharo recruitment plug: yesplan.be (Belgium) is hiring European Pharo software engineers. If you have little Pharo knowledge thatās fine too, in my (personal) experience, as I am now working with it for 3 months.
More on topic: there are many ways in which Pharo can find things that is not possible (or applicable) in other languages.
For example, there are 4 mouse clicks you can make in your image:
- left click
- right click: it shows a context menu
And then there are two clicks that I would need my laptop for to (re)figure out. One shows a āhaloā around a window. The āhaloā gives all kinds of options. The other one shows a context menu that allows you to figure out what objects are running with regards to the pixel you clicked on!
Because of the last click, itās easy-ish to extend your IDE.
The last two clicks are some combination of CMD + Option + CTRL + click
What is your pay for someone who could write this ten years ago in Amber Smalltalk but had since worked with Python and typescript?
https://m.youtube.com/watch?v=uUOlzr4XdcY
Asking for a friendā¦
Feel free to email me to have a more in-depth conversation. My email is in my profile.
Interesting, from: https://yesplan.be/en/vacancy/full-stack-software-engineer
> Our backend uses Pharo Smalltalk, Seaside and GemStone/S
How is your experience with GemStone/S?
For people that donāt know, GemStone is a smalltalk descendant that has an object-oriented database behind it.
I donāt know much about GemStone specifics yet, I am about to though.
My skillset before this was mostly in React and Node.
I used Gemstone/J for a number of years. This is the version of Gemstone DB for Java applications, same capabilities as the Smalltalk version. If you are familiar with Object Databases you will find it very easy and capable.
Before using Gemstone/J with a Java application, I worked in Smalltalk for a number of years building an application backed by a different object database product, so I was already familiar with the advantages and pitfalls of using an OO DB. If you are familiar with using an OO DB, Gemstone is an easy transition.
would you consider part time, remote?
I do remote-ish [1] for 4 days per week. I doubt they will do less days or more remote.
[1] I am at the office about every 6 weeks for 2 to 3 days.
We have been working for years now on a smalltalk like IDE and a language (which is as language not like smalltalk at all, but as runtime it is). When we went down the rabbithole of prior work (like smalltalk, lisp, etc), it is painful to notice how far we actually have come but how little we actually use / have available to us in mainstream dev. We hope to show how it should be later this year!
It's kind of depressing, honestly. Smalltalk is amazing future technology from the 1980s, and here we are in 2022 with our fancy IDEs still dropping off our (metaphorical) punch cards for batch processing.
Yep... Fairly bizar that a smalltalk env on an old computer is faster for iteration than the modern react/typescript stack. Better errors, easier to debug etc. All because the tooling was from the future. React peeps think hot reload is something special. It was normal and it was faster and more robust than it is now.
I think there's an inherent conflict between languages creating programs like clay to be molded by the developer and the user, interactively (repl, smalltalk), vs. languages creating programs with optimal machine code with no extraneous computations, and/or maximal low-level control (sometimes even at the cost of making it harder to alter code, like manual data structures or hand-rolled assembly or vectorization). I wouldn't call Smalltalk technology from the future, but rather optimizing for a different ideal (though I've never used Smalltalk to experience the magic firsthand (and/or smoke and mirrors, ctrl+f "white/blacklisting")). Smalltalk (like Java) is bound to a GC, and GC wreaks havoc with using finalizers for manual memory management cleanup, since finalizers can be called while a variable is still in scope unless you use GC.KeepAlive() or friends.
On the other hand, optimized C++ is notoriously hard to debug, and debug C++ is slow (especially when using "zero overhead" abstractions that are only zero-overhead in release builds). There's cool work at reversible debugging, binary-patching, etc. (low-overhead tracepoints, Linux kernel Kprobes which failed to hook some functions I think were actually called, CONFIG_DYNAMIC_FTRACE, most recently https://justine.lol/ftrace/, though both CONFIG_DYNAMIC_FTRACE and ftrace depend on injecting nops into code which can later be replaced by tracing code).
JavaScript excels at neither performance nor dynamism, though I think it's still a lot more dynamic than C++ (userscripts can tamper with page contents and scripting) and faster than Python (through herculean effort of the V8 developers funded by Google ad revenue to make web apps and advertising faster). And C++/assembly, by its nature of allowing complete control over the machine, is difficult to sandbox beyond running code in an isolated process or VM (or compiling to WASM then to x86?), as opposed to JS/WASM being (theoretically) memory-safe and sandboxable by taking away APIs interfacing to the outside world.
The problem is that developers have been brainwashed to dislike what Smalltalk has to offer. If you tell them to use a Smalltalk-like system they will complain to no end about the lack of file-centric infrastructure, while what Smalltalk has to offer is decades ahead of what they can do with other systems.
The problem is, what's the single best use case for Smalltalk?
Web apps are too dominant, and the fact is much of backend engineering is mildly unsuitable for a dynamic language runtime due to raw performance.
I think that's the issue. No golden use case like Ruby on Rails.
If Apple supported Smalltalk for native iOS apps things would be fine. But pigs would fly first.
Any recommendations on where to get started to understand the idea behind it, where itās used and how to approach typical problems?
In a much less interactive manner, the Unison language seems like it revolves around some stuff found in Smalltalk
How is version control usually handled in these kinds of systems?
> We have been working for years now on a smalltalk like IDE and a language
Iād be curious to know more about this!
Because it starts out in English and does not say so right away, I think it is a good idea to point out that the article is a google-translate, and seeing it in English I get a different idea in places than when reading the Portuguese.
For example, I had never before considered how this feature could help people navigate a foreign language so literally.
First time I saw the find by example feature I thought "maybe it tries all applicable methods" but then immediately dismissed the idea because it could execute methods with side-effects. Does Pharo somehow knows about safe/unsafe methods ?
The original method finder in squeak has a blacklist of methods not to try, but otherwise works just as you imagine. There's some very cool recent work on isolating effects at a low level that should obviate such grody hacks! Then the system really can freely and safely try all applicable methods. See thread up and down from here https://twitter.com/leastfixedpoint/status/15123917563183923...
I also noticed that the reimplementation uses `receiver deepCopy` for each message send to preserve the original object, so that side effects would not affect the receiver.
I don't think it really does. If I remember correctly, there's a bit of white/blacklisting going on under there.
Smalltalk code is full of these kinds of unprincipled solutions which work better than they should.
You can get away with a lot of saying "just trust me" when everything is exposed for immediate exploration of whether invariants are in fact preserved.
Does anyone know how to go to a specific implementation of a message for an object?
For example can I take "#(1 2 3) min." and go directly to the definition of min? It seems I can only look at _all_ implementations, not just the implementation for that object
Use the debugger to step through, and you will see the implementation that is about to be executed?
The debugger code itself could give clues on how to do it.
7 minutes of Pharo Smalltalk for Rubyists -> https://youtu.be/HOuZyOKa91o
The original description of the method finder was by Ted Kaehler in the July 2001 issue of SqueakNews. That electronic magazine was implemented in Squeak, but can now run in your browser thanks to the SqueakJS virtual machine:
Get a daily email with the the top stories from Hacker News. No spam, unsubscribe at any time.