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

pharo, like other smalltalks, doesn't really have much of a text editor - that's not how you write smalltalk code. instead, you use the browser, which has a text pane, to change/add things to classes (or indeed to objects). you have to think a bit different. and how do you expect to learn anything if you won't read or watch a tutorial?


> how do you expect to learn anything if you won't read or watch a tutorial?

I wanted to follow a tutorial (or another guide) to learn about Pharo, but couldn't find any, at least in the official docs. That's the point I'm making!


Did you download "Pharo Launcher" from https://pharo.org/download ?

Smalltalk in general is about a fully integrated environment, so everything lives inside of the environment, including applications, docs and also the tutorial.

Once you launched the Launcher, you create a image (latest stable, official distribution), launch the image, press the "Next" button until you see "You can learn Pharo by clicking on the following expression:" which launches the tutorial. That's about it.

And I did that the first time just now, without having any experience doing so in the past, or knowing 100% where to go. Everything was easily guessable. But I did know since before what a Smalltalk environment usually looks like, even though I haven't used Pharo specifically before for this.


That is a fair criticism! It is partially (maybe 20%) mitigated by the fact that this is a different lineage of computing and so you were going to hit a huge wall somewhere and when you got it here you reached out to the community and found folks like me to help you. But 80% of the point definitely still stands, this is a big change and there is not much documentation for you.

In this lineage of computing, you do not edit text files and then run a compiler and then run your tests and then cross your fingers and ship to prod. That is, if you like, the “Frankenstein” approach, you cobble together dead body parts into a chunk of dead code and then reanimate it with a lightning bolt. And it has eaten the world so uh can't really bash it.

But another lineage is preserved in spreadsheets and smalltalks, where that general outlook is considered a little barbaric and you want to instead be surrounded by your living, breathing program, with everything available to inspect and tinker with and test and replace. You run the image and you are launched into your running program. Yeah it doesn't do anything yet, because you haven't told it what to do... but here you are, ready to mold and model the compute like clay into whatever your imagination desires. The first few pots you throw, you're lucky if they don't collapse on you.

My standard example of the mentality difference is Object.become. Imagine I tell the standard Java developer, “we search through all of memory, find all private and public variables pointing to that object, and instead point them to this object...” They will look at you like you are nuts! But that’s essentially the underlying functionality needed for “you can edit the method and the entire system will start using your new method.”

So things like versioning and inspecting and editing are generally baked into the image rather than external tools because you want to be able to debug and undo your changes in vivo ... There is going to be an impedance mismatch, and the community can certainly make it easier on you for sure but there is going to be a lot of unlearning no matter what.


> My standard example

Ummm I daresay the vast majority of Smalltalk programmers never have (and never will) use become:


Think 'emacs' not 'C'. Smalltalk based systems are compete runtimes, a tutorial for Pharo is here:

https://ceronio.net/2017/07/first-steps-with-pharo-smalltalk...


Serious question: Can you create medium-size to large applications without a text editor?


It's actually one of the best parts of it.

Extreme TDD is amazing - you write a test, run it, and when it fails you basically fill in the chunk of code right from the error window and continue. It's not always super obvious how to get into the flow, but I found that although I didn't feel productive enough with the Pharo ecosystem, I _really_ miss the smalltalky development flow which foregoes using text files to organize code.


yes, pharo is basically written in pharo.

please note you _do_ have to type in code in text, but not monolithic amounts of it as you would in (say) a C++ program.


it's not that it doesn't have a text editor; most smalltalk windows have five or six text editors


Oh boy, how does one keep their sanity like that?!


The primary way of editing code in Pharo, Squeak, and similar implementations derived from Smalltalk-80 (but not all, some use the more familiar idiom of "many files in many directories") is to use one of the built-in (to the Smalltalk environment) browsers.

Select the package, class, and then method (or the options to create new ones) and the method will be in an editor pane for you. Start changing it, and the change is immediately applied once saved. No need to rebuild the world and restart the image. (Of course, that leads to some fun things where you can redefine True/False and break the image right there on the spot. Pharo seems to do a good job of blocking you from changing things like that so easily.)

Smalltalk code "lives" in a database. You interact with that database. The code is also serialized to a file if you happen to want more conventional access, but that's not the normal route. Though serialization to files is how Pharo and others allow you to interact with git and collaborate with other people.


you use the windows to keep them organized, same as in any other gui




Consider applying for YC's Winter 2027 batch! Applications are open till November 2.

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

Search: