Add new practice exercise bank-account

[jiegillet]

This is week 41 of 48in24.

This exercise is not straightforward, there are different ways it could be approached. Here are some notes:

• It is suggested that it's a good one for testing concurrency, but Elm can't do that on Exercism (since we need Task and a way to test them) so I did not implement the last test related to concurrency.
• In some languages, a stateful approach could be taken (a bank account is created and can be accessed by different clients), but we can't do that in pure Elm either.
• The way I would write this API in real life would be different, I would consider phantom types to only allow operations on accounts that are open. The problem with this approach is that it would get rid of a lot of tests that check for errors, and there are no way of looking at types with tests. We could do it with the analyzer, but that would be pretty unorthodox, and would require additional instructions. Doable though.
• There were two tests that checked that an account not opened could not be closed, but that just doesn't make sense in a typed language so I did not implement them.
• The API for the open function is quite unnatural, I wrote it this way to preserve as many test cases as possible and keep the spirit of the exercise as much as possible.
• I'm very happy that this exercise is suitable to be our first one to practice the opaque-types concept, since we don't even need to export the type.

I'm happy to discuss or revisit all of these decisions. The code is very simple, but the API is not.

[mpizenberg]

I just had a quick look and didn't find anything shocking with the code. But I don't know much of the context and objectives of the exercise regarding concurrency.

[jiegillet]

The code is fine, it's quite simple, it's the API (function signatures) that could be built differently.
The canonical data is a bit vague with it's "operations".
The last test is the one talking about concurrency.

[jiegillet]

@mpizenberg @ceddlyburge
I know that my description was long, but really if you don't have concerns, I'm fine with the exercise as it is. In a nutshell:

• we don't have concurrency, but that's not a requirement, so it's not an issue
• the API could be different, but this version allowed to keep the most exercises

[ceddlyburge]

Hi @jiegillet , I left this to matthieu as he got their first, but if he doesn't get back to you in a few days I'll take a look

[jiegillet]

We missed the 48in24 deadline, so this is not in any sort of rush at the moment, but @ceddlyburge if you have the time for a quick review, that would be nice.

[ceddlyburge]

I see what you mean about open being unnatural. I think it needs a comment or a mention in the instructions or something like that, otherwise we are teaching students bad practices.
Or we could split from the mainstream problem specification and create the problem in a functional programming way.
And it doesn't practice any race condition / parrallel execution stuff, so that part of the instructions is misleading.

Out of interest, is there data showing how many elm exercises are submitted as part of 48 in 24?

[ceddlyburge]

This is weird ...

[jiegillet]

Agreed.

[jiegillet]

Out of interest, is there data showing how many elm exercises are submitted as part of 48 in 24?

I don't know, maybe we should ask about that on the Forum, I'm sure other tracks would also be interested in having a breakdown of exercises submitted. It might already exist.

[jiegillet]

@ceddlyburge reading the instructions more closely, this whole exercise is really all about concurrency, for which Elm is poorly suited. This is the source of the unnatural API.

I don't think it's worth adapting to something Elm is suited for, it's not like the exercise has particularly interesting concepts outside of that (well, with the exception of being suited for having an opaque type).

Then instead, since this exercise is ill-suited for Elm, I propose to add it as well as parallel-letter-frequency to the list of "foregone" exercises, those are exercises that we choose not to implement. What do you think?

[ceddlyburge]

Yeah, I think that this exercise is about practicing concurrency, which is barely a thing in Elm, and 100% not something we can do within exercism, so we might as well leave it out. And the exercise is not particularly interesting, as you say ...