Forgive me for jumping into this mid-discussion, and admittedly I have not read every word of this thread, but...
I have understood that there are two primary points that William is promoting: 1) breaking-up the installation so that it becomes more-integrated with the system - such as logs going in /var/log, pid files going in /var/run, etc., instead of everything being under one common installation path. 2) breaking-up the code into multiple files in order to make it easier to digest, especially for prospective co-developers. If I have understood correctly, please allow me to respond in-line below... On 03/03/2016 07:05 AM, William L. Thomson Jr. wrote: > > That might be a good thing given the age of the code base. I do not believe > its ever had a complete redesign and code clean up. I believe it has just had > features added on over the years, as the file grew. Here you're suggesting that code quality will improve if it is refactored. This is not necessarily true. Refactoring also risks introducing bugs that were not there before. So, while the auditing that occurs during refactoring can be beneficial in optimizing and finding problems that were not obvious before, my experience is that there is also a considerable likelihood that problems that did not exist before will be introduced by the refactoring process. In my experience it is developer exposure, varied usage, and operational feedback that promote coding improvements. While code refactoring can increase these things, it can also restrict the same depending on how it's done (most developers need to be committed to it, users need to be committed to using it, and mechanisms for feedback need to be there to conclude that improvements have actually occurred). Given the push-back that your ideas are getting with Thomas, I'd say that you are unlikely to achieve the requirements for a refactoring to result in an improvement unless you somehow have several developers and a lot of users waiting to follow your ideas. > > NO, time well spent to make the code base more manageable. It will be in > smaller pieces that will allow others to more easily digest and contribute. > Not to mention making it like just about every other modern program and > project, code split across multiple files. This last bit about "just about every other modern program and project" is irrelevant and a red herring fallacy. Do you have some statistics on every other modern program and project to substantiate this? Or are you just explaining your own perceptions? In my experience there are a lot of well-used, good programs out there that are contained in one (or very few) code files. I, myself, work with both types. I don't perceive one approach to be superior to the other. Each method has its own strengths and weaknesses, and ultimately it really just comes down to developer preference. Some developers like to work with huge code files. Others prefer the code broken up into numerous files. Manageability comes down to developer preference. > > Its question if you want to be the ONLY one working on ASSP, or if you want a > more active development team furthering ASSP. Over the years seems like very > few are interested in working with ASSP codebase. I have tried to get several > I know who are VERY enthusiastic about perl and it is their go to language. > However all come back with the same complaint, and NONE are willing to get > involved as a result. I don't buy it. You may like to think that they would have gotten involved if things were different, but you don't know that for-sure. Even they, themselves, don't know that for-sure. There would need to be two projects - one written one way and the other written the other way - to know if they would have gotten involved with either. Your argument here is conjecture if not merely another red herring fallacy. In my experience developers who would get involved do get involved regardless of these kinds of things, and they will do the development in a way that they prefer - whether that is by working in cooperation with the existing developers or whether that is by developing their own fork. My experience is that developers who don't get involved wouldn't have ever gotten involved even if these kinds of things were different. They may *say* that they don't get involved because of these things, but when I have made efforts to accommodate potential co-developers in similar ways ultimately I find exactly what I'm saying. Generally speaking developers get involved only when they are motivated-enough. I have not seen developers get involved out of sheer academic interest and agreement with coding practices. Thanks, Lee. ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ Assp-user mailing list Assp-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/assp-user
