Hello, colleague. I'm also working in the same domain, primarily on the target of adapting the Actor model (async distributed messaging) for IoT systems in a wide: from deeply embedded nodes to top-level north-side cloud cervices. I like Pharo as a workstation system and IDE, but I'm not looking Pharo as a self-hosted platform for my needs. The problem is all IoT infrastructure it tightly bound with low-level C for nodes and Java for top-side. There are dozens and hundreds of existing projects, firmware source codes, platforms, etc which I must integrate with as is. As you know, Smalltalk is well known as bad in interaction with other existing projects, due to its architecture mostly close to the guest OS but not a programming language. If anybody doubts, try to use it the same way as Lua engine: embed into existing C#/Java project, or bind it with any randomly selected C++ library in a click, like Qt, LLVM, wxWidgets or something fat like this. The way looks me affordable to survive Smalltalk as a development platform is metaprogramming = code generation. We can build a domain model of the system we want to build (and integrate) and next generate C(++) source code by transpiling this model to the required target language. The Pharo gives as a very comfortable environment for model transformations, playing with transpilation and generic knowledge representation, and at the same time, it will not be involved in a target system we build. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

On Wed, 18 Dec 2019 at 16:12, Steve Davies <steve@connection-telecom.com> wrote:

Hi,

I'm having yet another go to get to grips with Pharo.

My project is for home automation. It seems in principle a great match since object inside Smalltalk are obviously a great match for physical objects being controlled.

I started at the Pharo Wiki on Github "Setting up a new project".

I'm a career programmer but I'm nearly 60 and sadly I can't absorb information like I used to be able to, and I'm just finding Pharo so overwhelming - I feel like a maintenance programmer trying to find a way into a million lines of code when you don't understand the principles of organisation and the conventions of the developers.

Consider the analogy would be someone wanting to write Hello World as a newcomer in C and having the source code for the Eclipse IDE in front of them and feeling like they have to understand all of that source code before writing Hello World. Just because because the code for the whole Pharo IDE system is front of you doesn't mean you should feel need to understand it all at once, or even ever. But I remember a similar initial jarring of my workflow before developing a constructive-ignorance mindset. Is there no way to have some sort of "progressive revelation" of the

insides of Pharo? Just documentation on most classes, examples of how to use the class, without the implementation being exposed initially?

The books and MOOC are probably the best for this https://pharo.org/documentation For something a bit more goal oriented, try Exercism... https://exercism.io/tracks/pharo-smalltalk The stuff I need to look into for my project is mixed in with 1000s of

classes that I (hopefully) can ignore for now - but there seems to be no way to hide away all the irrelevant stuff.

Traditionally if I was trying to get to grips with a large unfamiliar code base I would use grep to search, skim through source files getting a sense of it. With the browser in Pharo I feel like I'm looking through a keyhole. No doubt this is just unfamiliarity and I just need to learn the tools better.

A few things I find useful are: * In the class definition, select a variable the right-click-it > Code Search > References to it * In the Browser, select a class, right-click-it > Class Refs to find some unit tests using it, then debug-into those tests. * Make heavy use of Senders and Implementors to find examples of how things are used. * Add "self haltOnce" into methods so you can observe the call stack of how they are used. Note: "self halt" can be dangerous in system methods you're not familiar with, in case that method is used by the UI loop. haltOnce effectively stops the current UI loop and spawn a new UI loop to keep working. Personally I find it easier to understand the Pharo libraries by watching them run in a debugger than perusing static code. I'm looking forward to trying out the new object-centric-debugging... https://www.youtube.com/watch?v=uDYJIm54yE4 Please read this as a request for help as to how to get a finger hold and

how to shake this feeling of drinking from the firehose? It's not intended as a complaint.

Cool. It does read that way. Happy to help you settle in. cheers -ben

I've had the same experience myself. And now that I'm starting to introduce & teach Pharo to some of my colleagues (to build a users group where I work), I realize this can be a significant deterrent or stumbling block for newcomers. That's gotten me to think a bit about how to best address this issue, for myself and others. Now, as part of my introductions, I emphasize that "one of the hardest things about learning any object-oriented language is learning the base classes and methods -- because that's what you build */your/* application code on top of -- so you need to be familiar with it." Then I point out that you cannot learn the whole thing at once, but fortunately /you do not need to/. Adopting Pharo after a career of using other programming languages & environments can be a lot like changing operating systems (e.g., Windows -> Linux or Mac): You'll need to learn the basics to get started, then you add to your knowledge of what's there and how it works bit by bit as you realize there's something you need to know. You learn it incrementally. But there's already a lot there that's familiar in principle; the names, apperance, and locations are of course different. But "you know what /should/ be there... what's it called? where's it located?" The answers to these questions can usually be quickly found -- if you know the questions. ("What you know you don't know" versus "What you don't know you don't know'.) You can also pick something each day to research in Pharo, gradually getting more & more familiar. Experiment or watch videos, etc. Then I point out that Pharo has several tools & techniques to help with exploring and discovering classes and methods: * The Spotter, for quickly drilling down to what you need, or to reach a good starting place to begin exploring. * The Finder, including the ability to search by example. * 'Code search...' in the context pop-up menu (especially senders and implementers of). * The Playground: Provides a great way you can experiment with code snippets to see how things work; coupled with inspecting the results of expressions/statements, you can quickly get many starting points for further ideas. (If any readers can expand on this list, or phrase things better, please do!) One thing I did recently to experiment with the "explorable nature" of Pharo was inspired by noticing that in the Playground, if you "Print it" on an expression, the result appears in an ephemeral text widget; it disappears when you next click. But in other windows (most noticeably 'ProfStef'), the result is automatically pasted into the source's window. This can be useful, but sometimes it can be unwanted. (Yes, there is the option of "Inspect it", but "Print it" is quick and simple: "show me, then go away".) I wanted to know why it was different, and how... So I set off exploring, with the challenge of drilling down to the specific lines of source code deep within the base classes that produced each result, so I could see the difference in rendering "Print it" for these two cases. It was intimidating at first, but using the techniques I listed above (and two sessions, after the first one was "going off the rails" a little), I found both methods in a couple of hours. And it increased my understanding of "how it works". But it did something else, something a little intangible by comparison: It took away some of the mystery of "how Pharo works internally" (while boosting my appreciation of Pharo's brilliance in design and execution). Along the way I learned a bit about how some of these classes work, where they are in the hierarchy, and how they link together. Ultimately, my initial goal turned out be a much bigger challenge than I originally thought it would be: I wanted to see if I could mod ProfStef to *not* paste the "Print it" results into its own presentation window, and behave instead like the Playground. I found that the "column of classes" that lead to these two different behaviors are well-separated, and it seems to require the duplication of a lot of code to even begin do this; a simple override or extension to one or two base classes won't work. But it was satisfying to prove I can do this -- without help, on my own -- and boosted my confidence that I can "disassemble Pharo" whenever I need to, to answer these kinds of questions, find things, and learn the finer points of how they work & interoperate. -Ted -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html