> Во всяком случае оно было достаточно юзабельным, чтобы не уходить.На юниксах особенно некуда было уходить. А на всех остальных платформах никто массово долгое время и не приходил, пока мощности процессоров не возросли, стоимость памяти не обвалилась.
Можно ли было сделать не так тормозящий XUL? Можно, но для хорошей имплементации хорошей архитектуры нужно еще на порядок больше усилий.
> Да, пускать внутрь. Там же всё равно есть какие-то свои модули, верно?
> А если там они так мутно взаимодействуют, что без поллитра не
> понять
Не мутно, но сложно. Не всякое сложно - мутно, хотя и из наблюдений за софтверным ландшафтом чаще всего складывается именно такое впечатление.
Посмотрите на редкие хорошие проекты - LuaJIT, Yesod. Они не мутные, но они сложные.
> то либо разгребать
Уменьшать связность компонентов, упрощать логику их взаимодействия и увеличивать их размер? Будет очень медленно.
> либо хорошо документировать.
Этот кейс я описал. Он ничему не поможет. Либо это будет краткое, даже пусть и точное описание ("моноид в категории эндофункторов"), которое никому ничего не даёт, либо толстый учебник, который никто не будет читать и на поддержание которого в актуальном состоянии будет уходить 99% времени. К тому же таланты к написанию хороших учебников есть у довольно малой части популяции.
> Либо через год-два самого разработчика этот бардак догонит, что, собственно, с мозиллой сейчас и произошло
Это разные проблемы, в общем случае ортогональные. LuaJIT, например, бардак не догнал.
> Принцип "модули должны быть понятны стороннему человеку с разумными усилиями" - это как раз критерий хорошей архитектуры
Как лозунг на стенку для воспитания джуниоров в правильном духе - годится.
> особенно на сях, где бороться с бардаком сравнительно сложно.
От языка эти вещи очень мало зависят. В разных языках бардак выглядит немного по-разному и создается немного разными средствами - только и всего.
