The author doesn't touch on it much, but part of the added complexity is each person thinks differently too.
“Create a window with a table view, and then when someone clicks a button, add an entry to the table view”
If you asked a room of 30 people to draw you a picture of exactly what that sentence means, you will get 30 different results. Building on your comment, I'm not sure the actual act of programming would be hard if you had to take only 1 person's viewpoint into account and work off that.
If we figured out the best practice for common GUI cases (ex. in tables, shade every other row light gray), you could hide the complexity from the average program writer and make better decisions for them.
A GUI toolkit is already a set of best practices. Designing one is a difficult matter of balancing convenience with flexibility. Make it too basic and you complicate special cases and impede innovation. Make it too detailed and you force noisy code and wheel reinvention.
Right. I think that's why good toolkits have good default behaviors that you can also easily overwrite through well documented APIs. I think a good abstraction should let you also access the underlying layer for special cases.
An API designed for overriding still suffers from the same compromise. Any particular use case will want to override a specific set of functionality and nothing more. More fine grained overridability means more overhead complexity. Simplicity means you have to override functionality in large units, likely reimplementing most of it.
“Create a window with a table view, and then when someone clicks a button, add an entry to the table view”
If you asked a room of 30 people to draw you a picture of exactly what that sentence means, you will get 30 different results. Building on your comment, I'm not sure the actual act of programming would be hard if you had to take only 1 person's viewpoint into account and work off that.