config: replace problems key with exercises key

[petertseng]

#exercism/DEPRECATED.x-api#137 confirms it is safe to remove the problems key

All difficulties are 1, and topics are copied from problems.md

Completes two of the three steps in #179, with the only remaining step
being to assign difficulties.
This step will be completed at a later time.

Closes #195 via replacement

---

Question for reviewers: problems.md now duplicates config.json in both problem order (it was already duplicating it in this regard) and topics (added). So, what should we do about this duplication?

There is one piece of information in problems.md that is not present in config.json, if this PR were to be merged as-is: Section headers

## Introduction

The first section contains the sort of stuff you expect when learning any programming languages: conditionals, booleans, looping and some higher-order functions.

Option 1: We could do something really silly like "the first (not ALL, that is duplication) problem of a section gets a section_name and a section_description", like this:

    {
      "slug": "hello-world",
      "difficulty": 1,
      "section_name": "Introduction",
      "section_description": "The first section contains the sort of stuff you expect when learning any programming languages: conditionals, booleans, looping and some higher-order functions.",
      "topics": [
        "Some/None",
        "println!"
      ]
    },
   {
      "slug": "gigasecond",
      "difficulty": 1,
      "topics": [
        "crates",
        "math"
      ]
    }

(and so on)

Option 2: Keep the problem order duplicated in problems.md along with keeping the section headers there, but remove all topics from it, pointing to config.json as the authoritative source for the topics?

Option 3: Remove problems.md completely, losing our section headers.

Option 4: Keep problems.md as-is, accepting the duplication of topics.

Please also provide alternative options, if you have any.

I find option 4 completely unacceptable, but can be convinced of the other three options. My leading option is 1, and I will execute this option shortly after merging this PR if not convinced otherwise (I can even fold it into this PR if we want)

[petertseng]

should this be two separate topics?

[IanWhitney]

I think so.

[petertseng]

Original was Math, Struct. Enum, Trait, Box -- depending on implementation. Should Enum, Trait, Box all be on one line? What do we do with "depending on implementation"?

[IanWhitney]

I'd remove Trait, Enum and Box from there. I think I added those when I was trying a very different solution. Students might still use that approach, but it will be far from standard.

[petertseng]

This was automatically generated. I did not edit the config.json after it was automatically generated, except to then remove the problems key and to reorder the keys so that "deprecated", "forgone", "ignored" would come after "exercises"

require 'json'

config = JSON.parse(File.read('config.json'))
problems = File.readlines('problems.md')

def topics(problem_lines, slug)
  line = problem_lines.find { |l| l.start_with?(slug) }
  line.split(?|).last.split(/[\.,]/).map(&:strip)
end

config['exercises'] = config['problems'].map { |slug|
  {
    "slug" => slug,
    "difficulty" => 1,
    "topics" => topics(problems, slug),
  }
}

puts JSON.pretty_generate(config)

[IanWhitney]

problems.md may not be necessary after this change. I like that it describes our goal/philosophy of problem ordering, though. I'd like to find a way to keep that. But maybe that could be extracted into a new document.

[petertseng]

I like that it describes our goal/philosophy of problem ordering

Oh. You got me. That's one other thing (other than section headers) that problems.md has that this doesn't.

But maybe that could be extracted into a new document.

Ah. I'll think about whether it can possibly get merged into the README or something.

[petertseng]

Rebased for largest-series-product's addition. I think I'll merge soon and create an issue to discuss problems.md.