[erlang-questions] json to map

[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.

-- 
Hugo Mills             | Jazz is the sort of music where no-one plays
hugo@REDACTED carfax.org.uk | anything the same way once.
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/08e882eb/attachment.bin>