On Thu, Jul 30, 2015 at 05:18:00PM +0300, Nikita Karetnikov 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.
I think the #1 thing we devs can do for the project right now is finish the mechanism prototype. It has been waiting to be implemented for over two years, and now we're pretty close. In fact, we can't even write a spec until we have a prototype. Without something concrete to experiment with, no one can be expected to hit upon the right design. Thus, giving users (ourselves included) something they can play with is much more important than having full confidence in its implementation. There is a big difference between a public prototype, however, and a live website with real money. We can't go live with a prototype. I wouldn't dream of it, and I don't think it will happen. Switching from a prototype to a true implementation will require doing exactly the things you mentioned. We need a spec. We need a good architecture and separation of concerns. We need true unit tests and true integration tests. We need this for the financial Model if nothing else. There's two things we devs can do right now to make the project a success. The first, already mentioned, is to finish the freakin prototype. The second is to scrupulously catalog concrete examples of technical debt or potential refactorings in the code. Some code will have to be scrapped, some code will have to be refactored, and some is probably okay. The more evidence of technical debt we can gather, the more efficient we will be in paying it off. So, Nikita and everyone else, please keep pushing for better code. As "lead dev" part of my role is to balance your concerns with the concerns of the project leadership and other stakeholders. That means sometimes I might need reminders about what is really important to devs. :) But in this instance, I think we need to wait.
signature.asc
Description: Digital signature
_______________________________________________ Dev mailing list [email protected] https://lists.snowdrift.coop/mailman/listinfo/dev
