rjf> The chance that Machine Learning AI programs will find rjf> important algorithmic efficiency fixes in algebraic rjf> mathematical implementations seems pretty slim.
Improving code is something other than improving algorithmic efficiency of high-level algorithms, of whatever kind. The latter is certainly not an option yet. But as soon as such tools look simultaneously on written and compiled code new opportunities will arise. rjf> On the other hand, if you have gobs of code written by high rjf> school summer interns just learning Python, it is possible rjf> their code is filled with non-idiomatic and inefficient rjf> constructions that might be detected/repaired. The assumption that only the inexperienced beginner makes stupid mistakes or writes optimizable code is not likely to be shared here. But if, as you can seemingly imagine, such can be pointed to by checkers/optimizers, then the level of experience of the coder obviously does not matter. Between these two extremes are the daily necessaries of the programmer, and that is what it is all about. In this respect I find Volker's answer informative and revealing at the same time. vb> First we should add one of the plain old rule-based linters vb> to our testsuite, imho that would go a long way of maintaining vb> a consistent code style (and avoid trivial review friction). I have expected a lot of people answering Volker: "Hey, you are right, after the next release let's introduce such tools before we continue." Since such answers did not come in I gladly admit to having asked the question in the wrong place and at the wrong time. The question for me remains whether this reluctance towards such tools is typical for open-source/academic projects. Interestingly also Volker writes only about 'code style', not of other forms of improvements. I have the impression that the situation in the industry is quite different. rjf> It's your choice how to spend your time. Is it worth a try? You are absolutely right. I don't know any plausible estimate that the programming time developers spend for debugging is less than 50%; many estimates are significantly higher. But that's an old hat. P. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
