I feel like an overwhelmed maintenance programmer - how to get some toeholds?

Hi Steve,

Hi Steve,

Welcome!

Yes, Pharo and similar dynamic object system can seem overwhelming, but they are also powerful.

The trick is to find the shortest path from the system to your application, (re)using as much as possible. You should indeed also learn to skip over details and look at the interfaces of objects.

There are a couple of books, see http://books.pharo.org (and much more other documentation).

As for an MQTT client, that already exists: https://github.com/svenvc/mqtt

There is not much handholding documentation though, check out the unit tests.

Don't hesitate to ask questions.

HTH,

Sven

> On 18 Dec 2019, at 09:30, Sven Van Caekenberghe <[hidden email]> wrote:
>
> There is not much handholding documentation though, check out the unit tests.

Here is the class comment of MQTTExperimentalClient, which would be the one to use:



I am MQTTExperimentalClient.
I am an MQTTPrimitiveClient and a MQTTAbstractClient.

I am an experimental / proof of concept implementation of a simple MQTT client.

Examples:

Send a single message to a topic to the local broker, say a temperature reading of a sensor, using QoS level 1.

  MQTTExperimentalClient new
    atLeastOnce;
    open;
    sendMessage: 20 asByteArray toTopic: '/device/42/outside-temperature';
    close.

Same message to a remote host, using the default QoS level 0.

  MQTTExperimentalClient new
    host: 'iot.example.com';
    open;
    sendMessage: 21 asByteArray toTopic: '/device/42/outside-temperature';
    close.

Read a single message, using QoS level 2 (client should be closed afterwards)

  MQTTExperimentalClient new
    exactlyOnce;
    open;
    subscribeToTopic: '/new-user-notifications';
    readMessage.

Read and collect 10 temperature readings

  Array streamContents: [ :stream | | count |
    count := 1.
    MQTTExperimentalClient new
       open;
       subscribeToTopic: '/device/42/outside-temperature';
       runWith: [ :message |
         stream nextPut: message contents asInteger.
         (count := count + 1) > 10 ifTrue: [ ConnectionClosed signal ] ] ].

Collect 100 system notifications

  Array streamContents: [ :stream | | count |
    count := 1.
    MQTTExperimentalClient new
      host: 'iot.eclipse.org';
      open;
      subscribeToTopic: '$SYS/#';
      runWith: [ :message |
        stream nextPut: message.
        (count := count + 1) > 100 ifTrue: [ ConnectionClosed signal ] ] ].

Implementation note:

I use an inbox when reading messages so that I can store unexpected out of band messages.
Reading a message requires a condition filter.
I handle keepalive and ping.
I implement #runWith: to program in event driven style.

I just wish all « not much handholding documentation » was like that ;-)

And this are expression nice to debug (especially stepping into methods like #open, #sendMessage, #subscribeToTopic, …).

Cheers,

Cédrick

Steve - obviously there are a few books and tutorials to skim through, but worth mentioning the meta-enter key (eg Cmd-enter on Mac) - this is spotter which is a universal grep and browser to help find things, as well as users of things (and lots more tricks)

Also, in the playground is where you can evaluate code like a repl- if you use meta-g on an expression you get a results inspector on the rhs which lets you explore and keep sliding over panes as you dive in (great for looking at results). You can also teach your own objects to add useful tabs to that browser to get a cheap ui (useful for starting out)

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

I'm speaking about 20K SRAM computers and Java-only services. FFI and VMs do
not matter here.



--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Hi Steve,

Did you give a look at the "Smalltalk by Example" and "Smalltalk with
style" ? There are good starters to get an overall idea of the basic
objects and how is written Smalltalk code. It could help to jump in
Pharo then.

There are very easy reading, the advanced parts may not apply to Pharo
though, but you can then jump to specific Pharo books.

http://stephane.ducasse.free.fr/FreeBooks.html

Hilaire



Le 18/12/2019 à 09:11, Steve Davies a écrit :
> 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.
>
> 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?

--
Dr. Geo
http://drgeo.eu

Come on, there is

  http://books.pharo.org/updated-pharo-by-example/

which is the same book, but for Pharo, and updated to 5.0

And

  http://books.pharo.org/booklet-WithStyle/

being written.

Let's appreciate all the effort done by the authors to do the hard work of keeping all this up to date.

Keep cool and relax, no need to be harsh.  Just mention the additional
resources I will happily learn from, I did not see your previous posts.

I mentioned resources I was happy to use when learning Smalltalk, I am
only distantly following what is going on with Pharo. Last time I code
some bits of Pharo was about 2-3 months ago. Serious Smalltalk code was
likely about 12 months ago. I am recovering from a surgery where a big
part of my large bowel was removed and hoping for no relapse. So excuse
me if I am not up to the standard, I am not even a professional
programmer. My daily job is teaching to teenagers and staying afloat.

Thanks

Hilaire

Le 18/12/2019 à 19:00, Sven Van Caekenberghe a écrit : --
Dr. Geo
http://drgeo.eu

Hilaire,

I hope you are well.

I consider you a full member of the Pharo community, I have seen you interacting on the mailing lists for many years and I appreciate your work a lot, that is why I was surprised you would not know that there are newer, pharo specific versions of the very old book you mentioned, the Pharo By Example book is itself many years old already.

Please understand, many people ask for all kinds of documentation, authors put a lot of work in writing or updating documentation, and then it seems to go unnoticed, which is very frustrating.

Sven

Sven,

Often the intend is wrongly perceived, I am sorry about that.

I know about these Pharo books (but not the Pharo with Style which I did
not pay attention to), I bought three of them and I wrote the original
Morph chapter in the Pharo By Example book, I donated a bit to the Steph
proposal for additionnal resources (sorry forgot the name). For me these
resources are just obvious, and I just mentioned ones I have good
souvenir with when learning at the very beginning. I understand now it
felt like I want to ignore the Pharo documentation effort, but it was
really not my intend, I think I am over this kind of silly behavior, I
am sorry it felt that way.

Hilaire

Le 18/12/2019 à 19:39, Sven Van Caekenberghe a écrit :
> I consider you a full member of the Pharo community, I have seen you interacting on the mailing lists for many years and I appreciate your work a lot, that is why I was surprised you would not know that there are newer, pharo specific versions of the very old book you mentioned, the Pharo By Example book is itself many years old already.
>
> Please understand, many people ask for all kinds of documentation, authors put a lot of work in writing or updating documentation, and then it seems to go unnoticed, which is very frustrating.

--
Dr. Geo
http://drgeo.eu

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

The problem can be covered by a few experienced programmers who stream their
everyday work on a regular basis.
As I know, there is no anyone doing it.



--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html