On Fri, Jun 8, 2012 at 10:56 AM, Filip Pizlo <[email protected]> wrote: > > It's a lot harder to dive into, a lot more cumbersome to improve, and not > any easier to maintain. >
I definitely agree that NRWT is more complicated than it seems like it should be; it got contorted as we added all the features we needed to add, and I have been in a "simplify" mode over the past few months. I would welcome any feedback where you think things are overly complex. > The fact that it is unittested is part of the problem. It restricts what > you can do to the interfaces used internally in the code, which makes larger > changes much harder to pull off. It also steepens the learning curve. This is true. Of course, like all tests, it's a tradeoff. If it's not tested, it's very easy for one to change things and break some other feature that people need. > Look, the test harness should be a thing that helps us get work done, not an > end unto itself. The harness should err on the side of understandability, > hackability, and, in short, simplicity. I definitely agree that the harness should be a means and not an end. I of course like those ilities, too, but we also include functionality and performance, and both of those usually bring in complexity :(. > Python feels like the wrong technology to use for multithreading. I'm > curious if, in the future, next time we rewrite RWT (and I do believe that > there will be such a "next time"), we could pick a language that allows this > more naturally. It is true that Python's multithreading support is not great (it works as long as you don't need to interact with subprocesses, and as long as you don't need truly concurrent threads executing python code, because of the global interpreter lock). However,much of NRWT is built around a shared-nothing message-passing approach; do you think that was the wrong architecture, or would you have preferred to use a tool that had the same architecture but did it more easily (perhaps in something like Erlang)? -- Dirk _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
