The problem I have with the Coda approach, which is shared by other IDEs (and plenty of other kinds of software too), is that the interface components are overly specific to particular workflows and environments, and each tool complects multiple features/concepts. This (a) makes it harder to learn each individual part, (b) makes composing those parts to meet personal needs more difficult, and (c) makes it so learning those tools doesn’t point toward anything greater – you can’t take what you learn with you to new environments that weren’t anticipated by the original tool authors. Additionally, these kinds of tools tend to isolate users from the systems underneath, creating dependency. I much prefer when tool-builders think long and hard about making simple, orthogonal tools, designed to be composed together to meet diverse needs. As long as the individual components are explorable, such tools teach their users more fundamental concepts and allow them to grow over time.<p>When implemented well, an environment like Coda can be very productive in the niches for which it was designed, but in only offering a standard workspace and set of tools to everyone, it denies users the chance to build their own workspaces and pick & hone their own tools. This infantilizes and shelters those users, limiting them in the longer term.