Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I was excited to dig into Smalltalk some time ago, and downloaded Pharo 5. The reason I quit after a couple of minutes is that there was no support for standard Unix keybindings (i.e., C-a beginning-of-line), and no way to configure Pharo to understand them. [1]

Has this issue been solved in 6.0? I'd be happy to give it another go.

[1] https://stackoverflow.com/questions/38788468/pharo-keybindin...



What made you excited to learn Smalltalk? Seems odd that you quit after a few minutes. If keybindings are that important to you, perhaps try gnu Smalltalk.


I don't care much about keybindings, but I had a similar experience to GP. I used Pharo for a project and hated it. Not so much because it's "bad" per se, but the whole thing is running in a VM process in its own graphical environment, it's like a walled-garden kind of experience. I don't see the point in developing with it unless you are developing for it, so you have to buy into it completely or not at all. Whenever you ask Pharo people why it's better, the answer is always just, "Oh it's better.. trust me. I can't explain but it's about the image and .. well you'll know when you've tried it." You know what? I tried it. And it sucks. Pharo 5 crashed many times on me making me lose my work, so I got into the habit of saving the entire image every 5 seconds. Got tired of that pretty quickly.


Pharo 5 VM had a bug with a double free in the FreeType integration. So, using truetype fonts instead of the basic raster font made the VM crash. It took a while to find out why this double free occured. The crash was not from Pharo bytecode or the VM core, but from a stupid double free crash.

Now, why is it "better"? It is not because "trust me". It is because it makes code much more malleable. You need to let go of coding in files and of the need to scroll through code page after page. One needs to think of the code as a repository. Well the kind of thing tools like Jetbrains provides. When they do index your code, they basically build a Smalltalk image structure without the liveliness of it. So, the thing that makes me find it better is that when I got a bug (not a "crash"), a debugger pops out and I can inspect all of the state, maybe change code here and there (because I realized how stupid I was to code things that way 10 minutes ago), go back a frame in my debugger and continue the run. Without having had to stop anything, or restart the program. If I save my image before a run, I can always open it back like I would with a VMWare snapshot. That is quite great. After a while it reduces the time to code by a significant factor. Agreed it is another way to code. And ideed you'll know when you will have tried it. But it is hard to do all of that by oneself without seein g other Smalltalkers coding for real.

Now, for the files metaphor, I plan to have a fuse module at one point so that one can get into the image and see the contents as files, like one is looking into /proc or /dev etc. Then one can use Vim or whatever (I am a heavy tmux and vim user, so I feel your pain when it comes to the keybindings needs - but the current pain is worth the rewards). It took me a couple years to become proficient with Pharo and there is more to discover in that system for years to come. Because Pharo is a system and not a build system. You need to understand the system in which your code lives. This is very different from creating a piece of code from A to Z, compiling it and running it somewhat standalone or within, say, Tomcat or some similar device.

Also you shouldn't lose your work in Pharo because of the "Recover Lost Changes" tool that exists and allows one to grab the code back. Epicea brings this to a whole new level.

Hope this makes some of the possibilities a tad clearer.


Oh my problem is not at all with the idea of coding in an image, being able to dynamically change functions, etc. In fact I work that way all the time using emacs and Python. My problem is just being stuck with this annoying graphical environment that wraps it all.

And, I'll add, it's what gives it a feeling of being truly brittle when the whole thing comes crashing down. It's not just your program that dies, but the whole desktop. I'm glad to hear they found and fixed that bug, it was seriously detrimental.


Well, I am coding all day long in that thing and it is stable.

I do not feel stuck but have a few tricks: https://github.com/Pharophile/ExternalTools

(and for the save thing: https://github.com/Pharophile/HOImageSaver)

I like being able to add new features to my own dev environment the way I want. Like with https://github.com/Pharophile/TilingWindowManager

Try that with other tooling. A plugin or two, yeah, but hacking your own development environment from the inside out? That's really awesome I say.


Thanks for the information... I've had an interest in Smalltalk for a long time, but never really followed up b/c of the radical change in mindset (I've been a "CLI guy" for my entire career).

Having qualified my mindset, one thing I'd love to see is some way of "ssh-ing" into an image at least for being able to kick-off or inspect objects in a VM.

Perhaps in a related feature, having some kind of plan9/9p file server and/or client would provide a method to expose or consume data through a "standard" method.

Or maybe I'm mixing too many metaphors... at any rate, glad to see some activity in the Smalltalk/Pharo world here.


Ah, and about the "for it", you may want to have a look at scale, which lets you play with Pharo on the CLI.

https://github.com/guillep/Scale


Oh hello. That's the first I've seen it, basically what I was asking for. Thanks for the link!


Feel free to add new features! PRs welcome.




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

Search: