Here’s a peripheral argument to the current EF ruckus: Is the focus on visual tooling hindering the rate of innovation in the .Net world? At the ALT.NET event in Seattle, we started with a fishbowl session on polyglot programming (basically, using different languages and even writing little languages for the particular tasks that they’re best suited for). One of the attendees thought polyglot programming was a bad idea because of all the tooling that each new language was going to require. True, but hopefully false. High ceremony languages like C# and Java require more tooling like ReSharper and IntelliJ to be efficient than lower ceremony languages or terser languages. What if the alternative languages were usable for some specialized task without a lot of new tooling? Think about scripting languages or external DSL’s that are tuned for specific purposes and really don’t require Intellisense and wizardry to be useful.
Think about it, visual tools and user interfaces are expensive to build, but yet we automatically assume that a tool is “better” if it comes with Visual Studio integration and other visual goodies. Part of the cost of anything new Microsoft builds is a wizard tool or a VS plugin. That cost inevitably detracts from the development of whatever framework or technology that the wizard is meant to help. It’s an idle thought, but what if the Entity Framework team had focused on a textual DSL tool for configuration and modeling that was easy to use instead of relying on the more mechanically expensive designers? Or made the Xml mapping simple enough that you didn’t feel like the designer was necessary? Is it possible that they would have had more than enough time to make the structural changes in EF to allow for a Persistence Ignorance option in the first rollout? Instead of the wasteful arguments about the design of EF, I might be a happy, card carrying member of the “Entity Framework Mafia.”
All I’m really trying to say is that I think we could gain some benefits by downgrading our reliance on visual tooling and software factories and Visual Studio plugins in favor of API’s that are terser, easier to read, and easier to consume. My thesis is mostly based on my belief that language oriented programming techniques will often provide a greater return on investment than the comparable effort to develop visual tooling. Or we could just concentrate on making better API’s I suppose.
As an aside, a couple years ago I spent quite a bit of time trying to write a user interface tool to help users write the StructureMap Xml configuration. It was a mountain of work, and I gave up after becoming discouraged by the number of edge cases I needed to handle in the UI. A couple releases later I focused on DRY’ing up the Xml configuration to streamline it, bulked up the diagnostics, and added the Fluent Interface style of configuration. I’d argue that the Fluent Interface and Xml configuration improvements did enough to make the configuration easier that the UI tool is completely unnecessary. I certainly haven’t felt like I’ve needed it in my daily work. Now, I’d really like to get that very nice, early September day I wasted trying to write my StructureMap wizard instead of site seeing on the “Miracle Mile” in Chicago and going to the Field Museum. Priorities.
That last paragraph is partially meant as a warning for the Unity
team because they’ve got a visual editor on their CodePlex release plan. Trust me guys, there’s better ways to add value to Unity than
spending the necessary resources to write a visual wizard to write configuration.
A year or so ago (I couldn’t find the link), Ayende made the statement that any framework that required a wizard must have a terrible API. Assuming that he really did say that, and I’m not making that up, ditto from me. Don’t believe me? Pick any of the bigger 3rd party WinForms control libraries and try to configure their grid control without a designer.
One of my beefs about WPF (I do actually like WPF overall) is that the Xaml markup and object structure is clearly optimized for tooling rather than programmatic usage. It’s certainly possible to do dynamic layouts and DSL things with WPF, but it’s clearly not the way WPF is meant to be used and it showed. That’s really too bad because the actual technology behind the scenes seemed to be rock solid (once we wrote our Fluent Interface for dynamic forms it worked very well).
Just think, if we weren’t spending so much time as a community trying to build visual tools to make up for bad API design, how much more time we could have for “is the var keyword the work of the devil, or merely an occasional way to make code more readable?”