Discussion: concepts to implement
jiegillet opened this issue · 11 comments
I was thinking about some other concepts that we don't have at the moment.
I would love to have some opinions. We can leave this issue open to discuss that topic.
String => #536
That would be a simple one to add, we introduce the concept extremely quickly in basics-2 but mention almost nothing about the library. It's a very rich library, it would be nice to touch upon functions that are a little bit different in other languages, maybe like cons, uncons, words, toX, fromX...
Regex => ⛔
I know it's not used very often in Elm, but there are still cases where it's useful, and we provide the library, so why not. We can fork an existing concept for this, like this one.
Json Decoders => #538
This is usually a pain point for beginners, because the approach is very unique. Well worth a concept. There is one exercise using json input.
Random => #537
There are a few exercises that need it, and it's not an obvious thing in Elm, so it might be good to introduce.
The problem is that it's not possible to use without Platform functions, and we cannot test that without elm-program-test so we would need to add the dependency. However with this, we can introduce effectful concepts, like Task or the Elm architecture.
I agree with all these except Regex I think.
- String is a good idea to expand, there are many useful functions, especially ones that enables simple string processing like striping, splitting, etc.
- Regex can be very confusing, and as much as possible I'd like people to either use simple String functions for simple use cases of go for a parser approach for more complex setups. If we can reduce the total amount of regexes in Elm code bases, I see this a win ^^. Maybe instead of regex, we can have a "String processing" concept where we explain how to use String functions and/or simple parsers for common string processing tasks.
- Json decoders, yes very much agree a concept would be nice
- Random, yes and actually we can use random without Platform by using seed and steps. So we can either hide this in the test code and make students only write generators, or expose this feature somehow in the exercise (modifiable or in read-only file).
Oh, I went through the Random package but I somehow missed seeds and steps. Wonderful!
OK then, I'll create issues for these except for regex, I agree that it's a confusing technology that should be under String or Parser. Actually the parsing concept open with
Parsing is the process of transforming text into meaningful data. Functions from the String package are limiting in that regard and regular expressions are difficult to use, so the idiomatic way in Elm to parse is with the
elm/parserpackage.
Here are some things that I was thinking about.
- Elm architecture, would be cool to be able to write an app as a task that would run locally if you had installed the thing. Maybe even something from the existing guide.
- WebData / RemoteData
- Making impossible states impossible
- How to cope with large scale applications (I think people worry that Elm doesn't scale, as it doesn't have components)
- Some popular Elm things it is good to know about, such as:
- Create elm app / similar alternatives
- Elm review
- Elm UI
- Lamdera
- A GraphQL thing
- Maybe curate a list of further reading / watching (there are some excellent talks / blogs posts out there)
The frontend aspect of Elm is kinda hard to present to student considering the only interaction possible on exercism I'm aware of is testing and static analysis. Since the core team of exercism is taking a step back, maybe a good idea would be to participate in exercism upcoming discussions and see how tracks could be able to enjoy some of their specificities. For example, building webpages in Elm.
For tooling, it's also hard to teach considering the exercism platform makes it difficult to use. I guess we could add special cases in our runners to special-case some exercises, but I don't feel like adding complexity to a tool stack that is already not trivial would be a good idea.
Regarding elm-review, I could see a concept on static analysis instead, transforming code and ASTs.
An exercise or concept on making undesirable states unrepresentable (or as Richard says impossible states impossible) would make perfect sense. Could be providing some code with too many things and asking students to transform that code to fix it. This will be hard to write tests and analysis for though.
I think this code is fairly testable. init, update and view could all be tested, which is most of it. And the code is runnable so we could add instructions for that somewhere, even if we couldn't do it in exercism. Ellie or running locally or something.
https://guide.elm-lang.org/architecture/buttons.html.
I think this is possible too, although maybe a bit hacky. We could define dummy Lamdera functions in a helper fine.
https://github.com/lamdera/example-apps/tree/master/counter/src
Some of the other stuff might be better as a list of further reading, but I think with a bit of imagination and some dummy functions and things like that we might be able to do some things ...
What would you think of a Debug concept? It's worth learning about I think, we do tell the students to use Debug.log and the stubs usually have Debug.todo but they don't formally learn about it.
It would be strange to test though, I don't think the tests can catch the debug logs. Although we can test the output of Debug.toString and of course the analyzer could do it (although we would need a way not to run the NoDebug rule on a particular exercise).
A debug concept exercise would be good, but probably tricky to do, as you mention. Maybe that's fine though, it could be more of a reading exercise than an implementation exercise. We could also try and teach other Elm debugging techniques, and link to some useful content. It's something you see coming up on slack / forums every now and again.
What do people think about some Elm Architecture / Creating Websites type concepts? I'm keen to give it a try :)
Probably following the lines of the Elm Guide.
We already have the html module in our docker containers (although its an indirect test dependency, so it might want promoting), but we need to do something for Browser. I think a dummy module / supporting file would be easiest for this.
For Browser.sandbox, I think we would be able to test everything using elm-explorations/test, which again we already have in the docker files. We wouldn't be able to host the websites in Exercism, but we could direct students to copy and paste their code in to the online editor, or to create the app locally and run it if they wanted to.
For Browser.element, and the things it unlocks, things might get more complicated, and we might also want to provide a dummy module / support file for elm/http and maybe other things. I think this would be doable, but I haven't properly investigated yet. We could look in to this once the easier concepts / exercises were done.
I don't know if this is a good fit for the current exercism, the view and interactivity are the obvious problems.
The concepts are meant to be taught in the browser interface, not locally, so I wouldn't feel comfortable asking students to copy/paste code.
Browser.sandbox is at the limit of what could be achieved, but I don't think elm-explorations/test would be enough, we can't simulate user interaction with it, and interactivity is at the core of an Elm app. We would need something like avh4/elm-program-test (which I have never used so far).
I think requiring students to copy and paste code would be bad, but having it as an option at the end so they can see a thing working would be ok.
Elm is a language aimed solely at writing web applications (although it can be teased in to other things as well), so it seems a bit of a shame that a student could complete the exercism track and still have no idea how to write the simplest web application.
I think if we could test everything sufficiently using a combination of tests and the analyser then it would be better than nothing, and I'm hoping that this is possible (although I haven't got in to the nitty gritty yet). Some things will never be as good as writing the web app directly, as you can't look at it and debug and things like that, but I think it would still be useful to start students off with the general ideas and the basics.