[erlang-questions] json to map

[Hugo Mills]

On Fri, Aug 28, 2015 at 01:15:07PM +0200, Loïc Hoguin wrote:
> On 08/28/2015 01:04 PM, Roelof Wobben wrote:
> >Pity , you gave me the answer. Now I can do a copy/paste and go on and
> >the next time I do it wrong again.
> >That is why I want to try this one on my own and make my own mistakes
> >and learn from it , make more mistake and also learn from them.
> 
> Short piece of advice: if you do want to make your own mistakes and
> learn from it, *you have to find the solutions on your own*. Even if
> they are incomplete or barely working solutions.
> 
> Practice makes perfect. Not asking questions every time things
> doesn't work. Even if people don't give you the solution directly.
> 
> If you can't solve certain problems, it means you are lacking
> required knowledge, so move back to earlier problems and continue
> learning from there. Or try to give yourself a few gradually harder
> challenges until you get to the point where you can solve the
> problems you got stuck with.

   I second this.

   It seems to me that you're treating the exercises as a simple
checklist of things you have to do before moving on to the next topic.
That's not a particularly good approach to take. The world doesn't
need another implementation of counting the number of functions in
each module in erlang. What it does need is another person who knows
how to use list comprehensions and folds on structured data to turn it
into the desired output (whatever that desired output is).

   So... when you've done an exercise, don't just ask if the code
works. Ask yourself what that exercise was trying to help you to
learn, in the context of the chapter in question. An exercise asking
for a JSON parser may be written in exactly the same way, but will
have different learning goals depending on context. Consider:

 - You've just learned about I/O and binaries
versus
 - You've just learned about maps
versus
 - You've just learned about leex and yecc, the parser-generation tools

   In each case, your solution to writing a JSON "parser" is going to
look very different, because you're using the problem *to exercise
your new knowledge*. The author doesn't care about having another JSON
parser -- there's lots of them out there already. What they're trying
to do is get you to think about the problem *in terms of the thing
they've just taught you*.

   One thing that's missing in your questions here, and which is
leading inevitably to misleading recommendations (like using jsx or
leex in this particular case) is the context: you're not saying what
the goal of the learning experience is. As a result, you're getting
good general-purpose engineering solutions to the *problem*, rather
than things that will help you *learn*.

   The best people to listen to here are generally the ones who ask
you the awkward or difficult questions, because they're generally the
ones who are trying to get you to think about the problem in a
particular way. If you can answer those questions for yourself, you
will usually be thinking about the problem in a way that will get you
to the answer. If you can learn to think about problems in that way on
your own, then you will actually be able to write useful code. This
comes with practice, and lots of fiddling and failure on the way, but
it's not something that can be taught directly as a step-by-step
process to follow.

   So, to reinforce the primary point here: consider the exercises as
*practice* for what you were being taught, not as goals in their own
right. Do the practice, not "the exercises". The goal, for you, is to
be able to take the separate pieces and techniques and assemble them
into something that solves the problem at hand.

> Considering your recent questions, you clearly lack knowledge that's
> *very basic* so I am not sure why you start writing typespecs and
> parsers which are advanced topics.

   This is, I think, a symptom of the problems I've talked about
above. You do seem to have treated the exercises as "things to get
past", rather than "things to practice with". As a novice to
programming as well as Erlang, you may well have to have more
practice.

   As an extra exercise in each chapter, try coming up with your own
(simple) problem that shows off your skills with the techniques used
in that chapter. This has two parts to it: thinking of something
appropriate (which is itself a fairly hard problem), and then writing
the code for it (which is easier, if you came up with a suitable
problem in the first step).

   I used to be a mathematician(*), so I've got a whole raft of
interesting little exercises I can fiddle around with when I'm
learning the basics of a new language. Probably my first self-driven
code in erlang was something to generate all possible permutations of
a list. My first (and, to date, only) code in Julia was,
appropriately, a Julia set generator. If you have any kind of
technical or scientific training, think of a simple problem -- one you
could do on a piece of paper -- based on structures and concepts you
already know, and try to solve it in code.

   You should be thinking, when you read the text of your book, "ah,
now I understand, I could use this for <this-part> of
<my-problem-B>". Make connections with the things you already
understand and know how to do. See if the stuff in the new chapter
helps you understand any of the problems in the previous chapter any
better.

   That turned out to be longer than I originally intended. I hope
it's useful, anyway.

   Hugo.

(*) I'm better now.

-- 
Hugo Mills             | Great oxymorons of the world, no. 10:
hugo@REDACTED carfax.org.uk | Business Ethics
http://carfax.org.uk/  |
PGP: E2AB1DE4          |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150828/4d08f58d/attachment.bin>