On Friday, November 23, 2012 1:50:08 PM UTC, Nathann Cohen wrote: > Well. You have the right to like abstracton and generalizations. I prefer > to duplicate code to make things independent, and easy to understand.
Code duplication is a bug, plain and simple. If it doesn't fail outright then it is sure to cause somebody else grief in the future. You might think its easier to understand, but that is only because you put it there. The next person looking at it will be confused why very similar code is copy-pasted all over the place. Just say no to code duplication. That doesn't mean that you have to go to extremes in generic programming as Boost. But you should at least make an effort to understand the genius behind many of its modules. In fact, if your day-to-day code looks anything like Boost then you are doing something wrong. But if you design a library interface then I'd highly recommend it. I agree with you that there is a lack of documentation of some of the abstractions, though. Without documentation, an abstraction is just gibberish to most people and make it more difficult to contribute to Sage. Like the category stuff. Is there any way to figure out what they do without reading the source code? Why are things done the way they are done? A tutorial for using them? A tutorial for when and how to write a new category? -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/saaQ1_BMI2EJ. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
