On 07/30/2015 12:58 PM, fr33domlover wrote: > On 2015-07-30 > Nikita Karetnikov <nik...@karetnikov.org> wrote: > >> I have to admit the current mechanism implementation makes me uneasy. >> Everything is mutable and some functions, like underfundedPatrons, do >> too much, making it hard to test and even follow. >> >> When I start a new Haskell program, I usually try to express the core >> idea with types, making illegal states unrepresentable. Then, I write >> pure functions connecting the said types together, which compute the >> result. IO is only used on the edges (to receive and send the data). >> This is a very common technique. Can't we use it for the mechanism? >> >> How do you feel about this? I think the first step should be the >> rigorous spec of the things we care about, i.e., anything touching >> money. Then we follow the process described above. Testing becomes >> trivial because the core stuff is pure while IO actions are just >> reads/writes. > > > Sounds good to me (but I'm probably not the person to ask). I just wanted to > express a little thought: One of the strengths of Haskell is the advanced type > system and all the static verification it can give you. It means critical > things can be verified statically instead of relying on tests to catch them > (Yesod in general seems to take this approach seriously). > > All the m0ney related stuff is probably at least somewhat critical, so perhaps > more work with types could replace some tests. > > Just a random idea, I don't know how the code actually works right now :P > > > --- > fr33domlover <http://www.rel4tion.org/people/fr33domlover> > GPG key ID: 63E5E57D (size: 4096) > GPG key fingerprint: 6FEE C222 7323 EF85 A49D 5487 5252 C5C8 63E5 E57D > > >
I think we should have good typing for everything, we should rewrite the mechanism to be simple and straightforward. There shouldn't be the abstraction of "shares". The idea is simply a pledgeLevel which is the amount a patron actually says they pledge to donate per patron per month, and there should be patrons and accounts with funds. There need to be payouts, of course, and track the state of the accounts. The calculation for the pledgeValue that is the actual amount to donate at a payout should be determined by the pledgeLeval multiplied by the number of active patrons. I see no benefit to throwing in some concept of "shares" here. It was needed when we had a more complex formula. The more complex formula still makes conceptual sense, but is just not manageable presentation-wise. I know Bryan is talking about reimplementation already. Maybe he should post his plans / thoughts here. At any rate, we absolutely want to use strong typing and good Haskell practices everywhere here. There's *no* reason to assume that David's original implementation must be deferred to. It was never carefully spec'ed out or discussed or completed. I would love if he would weigh in, of course, to explain his thoughts about why he was setting it up as he did and what he thinks going forward, but I know he's very busy. In short: Nikita, I'm not sure why you think there's *anything* to defer to in the current code really. Whatever isn't the right approach should just be changed. But coordinate with Bryan, obviously. Cheers P.S. Everyone on this list: your thoughts are all welcome if you have opinions. Obviously, when we start talking details, it'll be easier to discuss. -- Aaron Wolf Snowdrift.coop <https://snowdrift.coop> _______________________________________________ Dev mailing list Dev@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/dev
