Nicolas, I know you respect his job very much and I have nothing against Mike Hansen of course. But these days I have been using Posets and Permutations a bit, and with Florent we found several problems already, and I am pretty sure you know muuuch more of them.
This thing with the permutations. The problem with Facade = False by default on Posets, see https://groups.google.com/forum/?fromgroups=#!topic/sage-combinat-devel/bfWbG54sedM There is also that bug about memory usage, 10 days ago : https://groups.google.com/forum/?fromgroups=#!topic/sage-combinat-devel/AdErcxGPq4c And there is also that THE INEQUALITY FOR POSETS IS BROKEN, because of "some thing you needed to add inside to have your computations go faster" (Poset inequality is only True if the cached linear extensions coincide), and "that cannot be easily changed because the code of a lot of people in Sage-combinat would be too slow otherwise". And none of these things ever get solved. What I have a hard time accepting is that you do not feel such things as dangerous, and bad, and the need to fix them quickly. These bugs have been reported and nobody who uses these classes everyday feels like fixing them. And the bug stays. Mike's work is all very nice, but it was 5 years ago. The code should have been rewritten since just by fixing things, step by step, as the bugs appeared. I have a very hard time accepting your development model. This Sage-combinat thing. The first time you told me about it, I think it was at the CIRM, you told me that "The goal was early integration". Ok, I can see a point to that (actually I don't, but I accept that you may, and hence I accept that answer), but look at all the problems it creates : * To me, Sage-combinat is a *FORK* of Sage. Because you work on Sage-combinat, and hence do not feel necessary to contribute to Sage, because if a thing is fixed in Sage-combinat you do not have a problem with it anymore. It's a fork. * You have "users", whom I call customers. I call them customers because you do a crazy amount of work for them (rebasing this damn patch queue) with the excuse that you cannot expect them to *UPDATE* their version of Sage by themselves. You told me several times that a patch could not be written because it would mess up with their code, or with its speed. Now you said that we cannot switch to GIT unless the Sage-combinat queue can be transferred to GIT too. Hell ! * You have one thousand patches there that are dying there. Last year I spent several days during the Sage Days in Cernay just trying to help write the documentation of one patch. Where is that patch ? Still in the combinat queue ? Same thing with Florent's patch on SearchForest. This is good code but I can already see how it goes : he works again on the code, improves that and that, and even though I tried to help him with the documentation I do not see the patch being submitted anytime soon. What is actually wrong, since he can already use it himself in Sage ? This is a bad developpement model. I mean, I can show two big problems (broken equality for posets, and this awful Facade thing) that you explicitely told me cannot be fixed because of the Combinat guys. You produce patches and do not write the documentation, because you do not have to, because your development model is "put whatever you want in the combinat queue, and you don't have to write a clean Sage patch because you can use it already like that". That's how I fix bugs in graphs : I write a patch, send it to the TRAC server, and forget about it until somebody comes to review it. Then I can totally forget about that bug. How do you propose we do the same with the constraints of Sage-combinat ? I saw three bugs, and all three have to be fixed. No problem with Mike's code. But not fixing bugs that you know exist is actual bad work. Some answers to points you raised in your post : > Granted, the refactoring of all this code is frustratingly long. But > there are a *lot* of efforts going on and things are progressing, one > step at a time (thanks everybody for that!). This will eventually get done. 5 years. Look at it. This was done 5 years ago. It has not been fixed. Let's be honest : it will NEVER be fixed. Not this way. Not by just waiting for it to happen. > And we should *not* remove that code in the meantime, because, as > crappy as it is, it still serves its purpose in waiting for something > better. If you want to add big fat warnings and some sanity checks, > sure go ahead. I like to play the dumb guy, and I love stupid methods like this one. And there is a big advantage to this method : if you remove it and everything breaks, the code will be replaced in no time. That's for sure, because everybody needs it. But for as long as you have a bad code, and because you don't feel the need to rewrite it, nothing happens. > But please be kind and unobtrusive to those who wrote > it and those who are working hard to improve it. Nicolas.... Honestly... I run code on my machine which you know is wrong, but it stays this way.. What do you call being unobtrusive ? Why doesn't it include to respect people by not letting them run code that you KNOW is wrong, and that they could legitimately trust a priori ? Nathann -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. 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.
