Here is a wonderful way our Program Manager John Stallo puts it…

 

“We want to complement the code editor, not substitute it.  Rather than provide a class diagramming experience where you can write and tweak every language feature from the designer as you can in the code editor, our goal was to optimize for designing and visualizing types in your project from a higher-level (i.e. the user is thinking about the top-level classes for their system and how they interact, not the deep, specific implementation details of one single class).  At the time you are deeply into implementation detail, switching to the code editor for those tasks is a natural transition.  The good thing is the user needn’t worry about the diagram becoming irrelevant, because we of course keep the diagram automatically in synch with the code.

 

Another way to put it is we don’t want users doing “visual typing” in our designer.  For many tasks, typing text in a code editor is a much more efficient way of doing things and we shouldn’t feel compelled to provide the same functionality in the diagramming space under the guise of “completeness”.  We focus on the tasks that are a better fit for the visual/diagram space and leave the things that are best done in a textual format to the code editor.”