<br><br><div class="gmail_quote">On Wed, Apr 20, 2011 at 9:24 PM, Kevin A. Smith <span dir="ltr"><<a href="mailto:kevin@hypotheticalabs.com">kevin@hypotheticalabs.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
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.<br>
</blockquote><div><br>xcellent<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
Abstractions aren't very helpful if you don't understand what they're abstracting.<br></blockquote><div><br>  Well said !<br><br>  One other point - years ago I taught programming (still do occasionally) and at the time I thought<br>
  "all I have to do is explain the abstractions" and that the student would immediately understand all<br>  the consequences of the abstractions (good programmers do, which is why it it's nice talking to them,<br>
  you tell the story and they fill in the details) but many programmers don't.<br><br>   I explained translative closures in Prolog (the good old related(A,B) :- ...) later one of the students<br>   was answering the question "what's Prolog good for" they replied "figuring out genealogical relationships"<br>
   they were completely oblivious to the fact that the solution to a problem in genealogy was isomorphic to<br>   the solutions to a large class of problems in unrelated problem areas. I then made up loads of<br>   examples.<br>
<br>   The point is, you can show people the generalization - but many will not understand the broad applicability<br>   of the  technique.<br><br>   The best way is to ask people what their particular problem is and solve it for them using the<br>
   technique you have just outlined (if it is appropriate)<br><br>/Joe<br><br><br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<font color="#888888"><br>
--Kevin<br>
</font><div><div></div><div class="h5">On Apr 20, 2011, at 6:16 AM, Joe Armstrong wrote:<br>
<br>
><br>
><br>
> On Wed, Apr 20, 2011 at 10:59 AM, Samuel Rivas <<a href="mailto:samuel.rivas@madsgroup.org">samuel.rivas@madsgroup.org</a>> wrote:<br>
> > Things become problematic when you do not entirely understand the<br>
> > abstraction.<br>
> > Maybe the abstraction is inappropriate for your needs. I have seen many<br>
> > examples<br>
> > of code where the gen_server *is* inappropriate. The acid test is "does the<br>
> > gen_sever code look like spaghetti" if the answer is yes then all you have<br>
> > done<br>
> > is shoe horn the applications into an inappropriate form. In this case<br>
> > you should ditch the gen_server and roll-your own.<br>
><br>
> Another problem I often see is that newbies tend to regard gen_server<br>
> as something that does magic, and fail to understand how the code runs<br>
> in the server and the clients (since that code lives in the same<br>
> module, usually).<br>
><br>
> They end up in solutions with parts of the gen server sending messages<br>
> back and forth, putting receives that spoil the abstraction<br>
> intercepting messages that gen_server code should be handling,<br>
> throwing exits in server code and attempting to catch them in the<br>
> client code, blocking servers with heavyweight operations, ...<br>
><br>
> I really consider advising against using gen_server (or any other<br>
> abstraction) until one is able to write a client-server and a<br>
> supervisor tree without them so that you can understand what's<br>
> happening under the hood of gen_server (which, as you say, it's not<br>
> rocket science).<br>
><br>
><br>
> Absolutely.<br>
><br>
> I think the problem stems from the use of IDEs - in eclipse/Xcode etc you click on<br>
> a "new project" button and the system automatically generates a load of crap files<br>
> full of incomprehensible undocumented nonsense. This leads to a mentality<br>
> of "using stuff without understanding it" - All I ever use is emacs, make and a shell.<br>
> Usually I put all the files in one directory. I want to understand *everything*<br>
><br>
> As IDEs get more and more complex and help you more and more<br>
> it gets harder and harder to understand what's really going on.<br>
><br>
> Graphics programming used to be easy - anybody remember Borlands turbo graphics?<br>
> - but now it's far more difficult since you have to fight with all the tools and<br>
> frameworks that get in the way and make life difficult.<br>
><br>
> /joe<br>
><br>
><br>
><br>
> Cheers<br>
> --<br>
> Samuel<br>
><br>
</div></div><div><div></div><div class="h5">> _______________________________________________<br>
> erlang-questions mailing list<br>
> <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
> <a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br>
</div></div></blockquote></div><br>