Just as a counter-point, I'm utterly unconcerned about fragmentation. This community is small, and the Arc codebase is small, in the grand scheme of things. It's tractable for one person to hold it in his/her head. We all have different strengths and weaknesses. If somebody finds it easier to work with C++ (that's me), go do it. If Common Lisp is your forte, and you find it easier to port Arc to it than to build threads into Racket-Arc, go for it. Regardless of where you are, it's tractable (though not trivial; write lots of tests!) to share code across projects.
One lament that often comes up with programmers is why software can't be as stable as a house or a bridge or whatever. Well, the reason is that our forebears tried lots of different houses and bridges before we settled on the ones we see today. That was only able to happen because of large amounts of fragmentation, only we don't call it fragmentation because atoms are harder to copy than bits, we just call it "trying again". Since bits are easy to copy, software culture has internalized some amount of "peer-pressure copying" under the banner of "avoiding fragmentation". I think it's silly. Particularly in the context of a small-scale project where there's never going to be much demand for deploying at scale, we'll never be a massive target for black-hat folks (so quickly transmitting security fixes isn't a priority), etc. Even for a large-scale project like Android, I think the problems people attribute to "fragmentation" are symptoms of deeper issues, and not fragmenting just keeps us from better understanding the issues.
That's fair. I definitely have a bias away from creating architecture, which probably explains more of my reactions than I'm comfortable with. I normally prefer to make things work within an existing system.
But yeah, I do see that it's worthwhile to try random things; it just doesn't feel true to me. For some reason, waterfall design is what makes me more comfortable.
