Feedback for OTP Tutorial Series

[oubiwann]

Leave your comments below for any issues, complaints, requests, etc., for the LFE OTP tutorial series.

[rvirding]

They are looking really great. This means I must get the LFE tutorial finished, and probably extended.

How are we going to handle suggestions for changes to existing blogs and errors? Can we just happily overwrite them?

[oubiwann]

Sweet! (About the LFE tutorial ... which I should also get back to helping with!)

Yeah, I think so. If we ever needed to refer to a previous edition, we could point to the markdown source in the repo ... but that probably won't be necessary.

[oubiwann]

I did notice that this was the convention in every bit of Erlang code that
I've seen. But I also remember when first coming to Erlang that this
confused me: I wasn't sure what was callback and what was gen_server (I
hadn't gotten used to the Erlang docs at that time either, so it was all
sort of a vague fog of "Erlang servers" ...

I've done a little tutoring of LFE lately using the approach of separating
the logic of the callbacks and the gen_server behaviour + API definition,
and folks seem to "get it" more quickly when I use that approach ...

Part of what I want to do in these tutorials is identify the Erlang
conventions that hinder initial comprehension by new users and postpone
introducing those until they are comfortable with the material ... maybe a
wrap-up post could go through each of the non-standard,
pedagogically-oriented convention-busters that were used in the posts and
show how these are more commonly done in Erlang libraries and applications?

On Tue, May 26, 2015 at 12:29 PM, Robert Virding notifications@github.com
wrote:

A quick comment on the gen_server: the standard OTP way is to define both
the API and the callbacks in one module. Seeing they have to know about
each other you might as well put them in one module. This is how basically
every gen_server in OTP is implemented. It is the same for the other
behaviours as well, one module.

Robert

On 25 May 2015 at 19:59, Duncan McGreggor notifications@github.com
wrote:

Sweet! (About the LFE tutorial ... which I should also get back to
helping
with!)

Yeah, I think so. If we ever needed to refer to a previous edition, we
could point to the markdown source in the repo ... but that probably
won't
be necessary.

—
Reply to this email directly or view it on GitHub
#7 (comment).

—
Reply to this email directly or view it on GitHub
#7 (comment).

[oubiwann]

Quick update: Robert has talked me into using the community-standard way of combining the callback and server modules. To make this easier to digest for newcomers, I'll need to rework some things and add more explanatory text.

The sorts of question I have gotten about this include (but aren't limited to):

• why do I have to type (MODULE) twice?
• why is there a separate parameter for a callback module when it's not used?
• what is a callback?
• what is a callback module?
• why doesn't a callback module have a behaviour if there are functions that it needs defined?
• what is a server module?
• how is a server module different than a callback module?
• if callbacks and servers are different, why is the code in the same module?
• if no one ever separates the modules, why does OTP make you say what your callback module is?

(Note that some of the earlier questions get asked again once they have more context and understanding.)

There are a bunch of other questions I've gotten from new users about setting up OTP servers, but they escape me at the moment. Oh, and there are a lot more for setting up supervisors.

But coming back to the point: I want to make sure that new users don't just have a Book of Convention thrown at them. Many of these questions go away if you just have them build things in a certain way and in a certain order and then explain conventions afterwards and show how conventions save in time/effort/etc. That's not so easy to guide in a blog post ... more thought required :-)

[rvirding]

I think the third reference about using call and then doing an explicit gen_server:reply and returning a #(noreply ... ) tuple will be be very confusing to newcomers. "What is this all about, and why don't you do it for amount?"

You will end up with users neither doing gen_server:reply not return #(reply ... ) so their callers crash (timeout), or doing both and the mail queues building up, or ... No keep it straight forward: in handle_call you return a #(reply ...) and in cast you return a #(noreply ... ).

There are some specific cases when you want to do this but it should definitely go in the final OTP for experts blog.

[oubiwann]

Thanks for the feedback! I'm re-doing the post now (splitting it into two,
as it's getting too long), and I will remove that note.

On Thu, May 28, 2015 at 8:48 AM, Robert Virding notifications@github.com
wrote:

I think the third reference about using call and then doing an explicit
gen_server:reply and returning a #(noreply ... ) tuple will be be very
confusing to newcomers. "What is this all about, and why don't you do it
for amount?"

You will end up with users neither doing gen_server:reply not return
#(reply ... ) so their callers crash (timeout), or doing both and the mail
queues building up, or ... No keep it straight forward: in handle_call you
return a #(reply ...) and in cast you return a #(noreply ... ).

There are some specific cases when you want to do this but it should
definitely go in the final OTP for experts blog.

—
Reply to this email directly or view it on GitHub
#7 (comment).