Closed kytrinyx closed 7 years ago
I'll keep this PR open until we finish at least the first two - maybe all - of the three proposed stages:
Now that we finished stage 1 of the migration, it is time to give approximate difficulties to all the exercises (stage 2). :smile:
I'll just paste here an unfinished exercise's classification, so that in the future I, or someone else, can continue from where I stopped.
triangle { Math (Triangles ) }
leap { Math (Integer division) }
difference-of-squares { Math }
ocr-numbers { Strings }
pig-latin { Strings }
series { Lists, Strings }
crypto-square { Lists, Strings }
anagram { Lists, Strings }
beer-song { Lists, Strings, Refactoring }
house { Lists, Strings, Refactoring }
food-chain { Lists, Strings, Refactoring }
kindergarten-garden { Lists, Strings, Maps }
scrabble-score { Lists, Strings, Maps? }
bob { String, Parsing }
sum-of-multiples { Lists, Math (Factors ) }
luhn { Lists, Math (Integer division ) }
palindrome-products { Lists, Math (Palindromic numbers) }
prime-factors { Lists, Math (Prime numbers ) }
pascals-triangle { Lists, Math (Pascal's Triangle ) }
sieve { Lists, Math (Prime numbers ) }
raindrops math { Strings, Math (Integer division) }
largest-series-product { Strings, Maybe }
queen-attack { Strings, Maybe }
grains { Math, Maybe }
hamming { Lists, Maybe }
atbash-cipher { Lists, String, Maybe }
allergies { Enumerates, Deriving type-classes, Math (Numeric encoding), Lists }
all-your-base { Math (Numeric encoding), Lists, Folding, Maybe }
binary-search-tree { Data Structures (Binary Tree), ADTs, Deriving type-classes, Folding, Recursion, Maybe }
clock { ADT, Deriving type-classes, Instantiating type-classes, Math (Integer division) }
custom-set { Lists, ADT, Deriving type-classes, Library reimplementation }
word-count { Strings, Maps }
etl { Strings, Lists, Folding, Maps }
lens-person { Lenses, Record-syntax, Calendar }
accumulate { Lists, Recursion, Library reimplementation, Lazy evalutation }
list-ops { Lists, Folding, Library reimplementation }
nth-prime math, filter { Maybe, Lists, Math (Prime numbers) }
nucleotide-count { Either, Maps, Strings }
parallel-letter-frequency { Maps, Text, Parallelism }
phone-number { Maybe, Strings }
rna-transcription { Pattern matching, Lists, Maybe }
roman-numerals { Strings, Maybe, Math (Numeric encoding) }
saddle-points { Arrays, Lists, Math (Saddle Points) }
say { Strings, Math (Numeric decomposition), Maybe }
secret-handshake { Typeclass (Creating a typeclass and instances), Strings, Math (Binary Encoding) }
sgf-parsing { Data Structures (Tree, Map), Maybe, Text, Parsing }
space-age { ADT }
grade-school { ADT, Maps, Sets, Lists }
meetup { ADT, Calendar }
robot-simulator { ADT, Strings }
sublist { ADT, Lists }
pythagorean-triplet { ADT, Lists, Deriving typeclasses, Math (Pythagorean triples) }
simple-linked-list { ADT, Library reimplementation, Lists, Folding }
matrix { ADT, Deriving typeclasses, Vector }
bank-account { ADT, IO Monad, Maybe, Mutable State }
linked-list { ADT, IO Monad, Maybe, Mutable State }
robot-name { ADT, IO Monad, Mutable State, Random }
simple-cipher { Strings, IO Monad, Random numbers }
strain { Library reimplementation, Recursion, Non-strictness, Folding? }
wordy { Parsing, Maybe, Strings }
change { Math (Knapsack type problem), Maybe, Lists }
minesweeper { Grids, Strings, Lists }
zipper { Zippers, Maybe }
pov { Data Structures (Trees), Zippers, Maybe }
connect { Graphs (Undirected graph), Strings, Lists, Grids, Maybe }
forth { ADT, Deriving type-classes, Text, Strings, Either, Maps, Parsing }
go-counting { Strings, Lists, Sets, Maybe, Graphs (undirected graphs), Grids }
I found an old list I made at https://github.com/exercism/xhaskell/issues/193#issuecomment-233520105 , I might take a look at it sometime and see whether that has any useful information thta can go here.
This list of topics I made was initially based on you previous classification. Forgot to give the credits, sorry! :smile:
Sometimes I feel like just taking the https://github.com/exercism/xhaskell/issues/274#issuecomment-253597062 list and adding it to the config.json, unmodified, just so that we can say this got done.
But other than the satisfaction of being able to close the issue, there is too little incentive to get this task done. The topics don't show on the site, so the only possible benefit is maybe we can reorder the exercises based on what we observe from the topics.
But we already reordered the exercises on difficulty, so we may not gain much from that.
Being able to reorder the exercises in a reasonable way was what gave the incentive to add the difficulty ratings, of course.
@petertseng Let's do this without the difficulty rating. We aren't using it for anything yet, and when we do we'll be way more motivated to actually add them.
Sometimes I would like to know - all the exercises in this track that use Maybe
. All the exercises that use Result
. All that use algebraic data types. Today, I would use grep for this. But maybe we can put it in the topics section. But fear that it will get out of date! But maybe it's time to let go of that fear. After all, how often does the list of problems change?
Or you know a crazy dream of mine? That at least these elements of the topics section can be automated.
By the way, I hope I don't sound too harsh or critical.
I say that because a very pessimistic reading of my comment is that I am complaining that higher powers have handed down a task of no benefit and that I am in active rebellion against the task. Now, I don't think that anyone is going to read it that pessimistically, but I could believe that someone will read it slightly pessimistically.
What I see here is:
exercises
not problems
, add difficulties, add topics.At this time, I decided to add a few topics that I feel the track will derive benefit from. Then I propose we can consider this issue complete.
It didn't sound pessimistic to me. I think it was opportunistic to consider adding the difficulty ratings, but more practical to not do so right now. I'd like to be able to intelligently order exercises better, and I suspect that we might do so eventually (and maybe not with the difficulty rating).
It is a little unfortunate to leave the work in https://github.com/exercism/xhaskell/issues/274#issuecomment-253597062 hanging, but I felt that trying to maintain all that information would require a lot of mental effort and not enough benefit.
But my hope is that if the time comes to flesh out the topics, we can revisit that work, since I imagine things will not have changed too much with the exercises. We can also add more topics as time goes by, if we see that they are relevant to making ordering decisions.
An implicit consequence of the way this was done: The current topics in config.json would be of use for students if suddenly they were appear on the website today, but the primary use is for track maintainers so that we can understand our problem ordering.
For the past three years, the ordering of exercises has been done based on gut feelings and wild guesses. As a result, the progression of the exercises has been somewhat haphazard.
In the past few months maintainers of several tracks have invested a great deal of time in analyzing what concepts various exercises require, and then reordering the tracks as a result of that analysis.
It would be useful to bake this data into the track configuration so that we can adjust it over time as we learn more about each exercise.
To this end, we've decided to add a new key exercises in the config.json file, and deprecate the
problems
key.See exercism/discussions#60 for details about this decision.
Note that we will not be removing the
problems
key at this time, as this would break the website and a number of tools.The process for deprecating the old
problems
array will be:In the new format, each exercise is a JSON object with three properties:
The difficulty rating can be a very rough estimate.
The topics array can be empty if this analysis has not yet been done.
Example:
It may be worth making the change in several passes: