[erlang-questions] json to map

[Roelof Wobben]

Op 28-8-2015 om 15:11 schreef Hugo Mills:
> [Roelof, apologies for missing you out on the cc on my last mail -- I
>   hope you got it through the mailing list. I don't know how that
>   happened.]
>
> On Fri, Aug 28, 2015 at 12:27:14PM +0000, Hugo Mills wrote:
>>     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.
>     Sorry to drone on here, but I wanted to follow up on this point a
> bit.
>
>     Most problems in CS don't have linear paths to the solution. You
> don't just start with "here's the input, so I do this, do this, do
> this, and there's the answer". You have to pick at them around the
> edges, find the pieces you know how to do. Consider doing something
> because it looks like it might get you closer to the structure you
> need. Work from both ends at once: you have some data as input, and
> you want a particular structure as output; what can you do to the
> input to simplify it? What's the simplest data that you could use to
> generate the output, and how would you do it? Do those two meet in the
> middle? If not, try again and work the edges towards each other. Is
> there a simpler version of the problem you *can* solve? Do that first,
> then see if you can modify it to deal with the other pieces.
>
>     Example: For this JSON-parsing problem, what's your input? (I'd
> guess you just read the whole file in as a binary or a string to start
> with -- pick one, do it; bear in mind what the chapter is trying to
> teach you, as this may make a difference in which one you pick). Given
> input in that form, if the first thing in your input is a plain quoted
> string, can you turn that into an Erlang string and a piece of unused
> input? Do that. What about a number to an Erlang number? Do that. An
> unquoted string to an atom? Do that. Can you turn a simple JSON array
> into an Erlang list of terms (and some unused input)?  Do that. Can
> you modify that to parse an array of arrays? Do that. Can you turn a
> simple non-nested JSON map into an Erlang map (or dict, or whatever)?
> Do that. Can you use those as building blocks to parse a full JSON
> structure? You're done. It'll be a pretty useless JSON parser for
> practical purposes, but that's OK, you're just learning. (To repeat my
> last email, the output of your work is not a program; the output is a
> programmer).
>
>     Try writing down (in your own language) a problem description for
> each of the stages above, and treat it as a self-contained problem.
> Some of them will be trivial. Some will be a bit more complicated. The
> later ones will build on the earlier ones. Write code (or modify
> existing code) for each one. Being able to do this -- break a problem
> down into separate pieces you know how to solve -- is the essence of
> writing software, and it's the hardest thing to learn how to do well.
>
>     Hugo.

Thanks for the advise.

Roelof