[erlang-questions] The gen server simplified (how it works)

[Joe Armstrong]

On Wed, Apr 20, 2011 at 9:24 PM, Kevin A. Smith
<kevin@REDACTED>wrote:

> Strong agreement with everything stated. When I teach an "Intro To Erlang"
> class I spend a lot of time (lecture and labs) working on the basics before
> we tackle gen_server. In fact, one of the last labs before getting to
> gen_server requires the class to write their own server very similar to
> Joe's code.
>

xcellent


>
> Abstractions aren't very helpful if you don't understand what they're
> abstracting.
>

  Well said !

  One other point - years ago I taught programming (still do occasionally)
and at the time I thought
  "all I have to do is explain the abstractions" and that the student would
immediately understand all
  the consequences of the abstractions (good programmers do, which is why it
it's nice talking to them,
  you tell the story and they fill in the details) but many programmers
don't.

   I explained translative closures in Prolog (the good old related(A,B) :-
...) later one of the students
   was answering the question "what's Prolog good for" they replied
"figuring out genealogical relationships"
   they were completely oblivious to the fact that the solution to a problem
in genealogy was isomorphic to
   the solutions to a large class of problems in unrelated problem areas. I
then made up loads of
   examples.

   The point is, you can show people the generalization - but many will not
understand the broad applicability
   of the  technique.

   The best way is to ask people what their particular problem is and solve
it for them using the
   technique you have just outlined (if it is appropriate)

/Joe




>
> --Kevin
> On Apr 20, 2011, at 6:16 AM, Joe Armstrong wrote:
>
> >
> >
> > On Wed, Apr 20, 2011 at 10:59 AM, Samuel Rivas <
> samuel.rivas@REDACTED> wrote:
> > > Things become problematic when you do not entirely understand the
> > > abstraction.
> > > Maybe the abstraction is inappropriate for your needs. I have seen many
> > > examples
> > > of code where the gen_server *is* inappropriate. The acid test is "does
> the
> > > gen_sever code look like spaghetti" if the answer is yes then all you
> have
> > > done
> > > is shoe horn the applications into an inappropriate form. In this case
> > > you should ditch the gen_server and roll-your own.
> >
> > Another problem I often see is that newbies tend to regard gen_server
> > as something that does magic, and fail to understand how the code runs
> > in the server and the clients (since that code lives in the same
> > module, usually).
> >
> > They end up in solutions with parts of the gen server sending messages
> > back and forth, putting receives that spoil the abstraction
> > intercepting messages that gen_server code should be handling,
> > throwing exits in server code and attempting to catch them in the
> > client code, blocking servers with heavyweight operations, ...
> >
> > I really consider advising against using gen_server (or any other
> > abstraction) until one is able to write a client-server and a
> > supervisor tree without them so that you can understand what's
> > happening under the hood of gen_server (which, as you say, it's not
> > rocket science).
> >
> >
> > Absolutely.
> >
> > I think the problem stems from the use of IDEs - in eclipse/Xcode etc you
> click on
> > a "new project" button and the system automatically generates a load of
> crap files
> > full of incomprehensible undocumented nonsense. This leads to a mentality
> > of "using stuff without understanding it" - All I ever use is emacs, make
> and a shell.
> > Usually I put all the files in one directory. I want to understand
> *everything*
> >
> > As IDEs get more and more complex and help you more and more
> > it gets harder and harder to understand what's really going on.
> >
> > Graphics programming used to be easy - anybody remember Borlands turbo
> graphics?
> > - but now it's far more difficult since you have to fight with all the
> tools and
> > frameworks that get in the way and make life difficult.
> >
> > /joe
> >
> >
> >
> > Cheers
> > --
> > Samuel
> >
> > _______________________________________________
> > erlang-questions mailing list
> > erlang-questions@REDACTED
> > http://erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110421/76684eeb/attachment.htm>