On Sat, Oct 27, 2012, at 16:51, Juliusz Chroboczek wrote: > Boutier and Kerneis have made available a draft of their latest paper: > > Matthieu Boutier, Gabriel Kerneis. Generating events with style. > Submitted for publication. October 2012. > > > http://hal-univ-diderot.archives-ouvertes.fr/docs/00/74/29/02/PDF/kerneis-boutier-2013.pdf > > Pages 5, 6 and 9 constitute a good analysis of why Polipo is > unmaintainable. (Note that this is a draft, and hasn't been peer > reviewed yet.)
With respect I don't think that suggests that Polipo is unmaintainable. I have done asynchronous programming in a variety of ways in a variety of programming languages. My current preferred method of creating single threaded programs in C++ is a to have blocking function calls return futures (structures that represent the value that will be fulfilled in the future) which on which callbacks can be set. You can then do a transformation from a synchronous function returning T to an asynchronous one returning Future<T> by putting all the stack variables into a class and making each non-blocking step of computation member functions the last action of each is to chain to the next one. This is similar to the callback with minimal data structures style discussed in the paper. Anyway, I digress. Having read through the source code to Polipo and produced patches to it I would say that while sometimes following the control flow was slightly challenging this was offset by: * The lack of dependencies meaning that one only needs to understand the standard C library and the concepts within to understand Polipo. It doesn't make use of any fancy frameworks which you would first have to understand the underlying concepts for. It also means that if there are any issues they are almost certainly in the 10000 lines or so of Polipo rather than 100000 lines of framework, etc. * The size of the implementation. There are only 10000 lines of code. Ultimately this puts some upper bound on the level of complexity of the system. * The fact that Polipo is free and open-source software. It reaches an larger audience of testers and developers and so the project is in a better position to understand and make correct generalizations rather than a project with a narrower reach. * The fact that Polipo is already a mature implementation. This means that maintainership should mostly consist of dealing with bug reports, fixing small bugs here and there and accepting unobtrusive new features rather than frequent overhauls of the code base with a lot of code churn * The fact that Polipo is just a simple C program means that there is a huge amount of tooling to help validate and track down errors. This includes both static (compiler, coverity, etc.) and run-time checkers (valgrind, etc.). In addition the tooling that is actually used to produce the program (gcc, etc.) is likely to be reliable and bug free for Polipo's purposes. Sometimes it seems to me that the academia likes to focus on certain aspects such as static analysis, provable correctness, etc. whereas it will ignore some of the less glamorous engineering realities that make building, and especially maintaining software difficult. It may also ignore the far more important personal factors which affect software and the context within which it is built and maintained. Polipo could be re-written in any of the styles proposed in the above paper and it would have a lesser effect on the maintainability of the codebase than any of the aspects I listed above. For the personal I believe that the reason Polipo has any of the above characteristics is due to the mature and disciplined approach *you*, Juliusz Chroboczek, have taken. In summary Polipo is maintainable and popular in my opinion, not because of the big technical decisions that you have taken such as your approach to asynchrony, but because of the many small technical and non-technical decisions you the maintainer have made on the way keeping Polipo simple, focused, free. In my opinion the biggest barrier to easy maintainership and the reason that you have found it difficult to find a replacement for yourself as chief Polipo maintainer comes down to two aspects: * The lack of automated tests. Making changes to a mature code-base requires confidence that you are not breaking anything or otherwise causing regressions to any of the requirements on that codebase. This means there needs to be some knowledge of both the diverse way the code is used, how it's expected to behave and how a particular change can affect these use-cases. In Polipo's case this information is encoded in your head and it would be a great effort on another's part to reach that same level of understanding. With good automated tests this information is encoded in the tests so someone can be an effective maintainer even if their understanding of both the software and the problem domain is incomplete. * The fact that the current master branch is not release worthy and only you know why and how means that there is a lot of work for a new maintainer to do before the fruits of their labour pay off. The conclusion states: > An interesting extension of our work would be to try and reverse our program > transformations, in order to reconstruct threaded code from event-driven > pro-grams. This could help analysing and debugging event-driven code, or > migrating legacy, hard-to-maintain event-driven programs like Polipo towards > CPC or other cooperative threads implementations. I think the paper is an interesting academic and intellectual exercise but demonstrates immaturity from a software engineering perspective. It is my belief that, while using cpc or something similar might have made Polipo easier to write in the first place (as would writing it in some other language which translates to C such as vala) given the two options I would choose Polipo as it is now. I therefore think that that makes Polipo *better* as it is than as it could be as described in the paper. Thanks Will ------------------------------------------------------------------------------ WINDOWS 8 is here. Millions of people. Your app in 30 days. Visit The Windows 8 Center at Sourceforge for all your go to resources. http://windows8center.sourceforge.net/ join-generation-app-and-make-money-coding-fast/ _______________________________________________ Polipo-users mailing list Polipo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/polipo-users
