The discussion on the last post suggested Domain Specific IDEs as a possible way forward. By restricting the domain (e.g. games) the IDE might gain enough semantic insight into the program to properly support advanced interaction designs like live code execution and direct manipulation of results. Well here is a perfect example: the Iguana Translator. These guys have done a great job building an advanced programming experience for the domain specific problem of mapping between data formats. I love seeing new ideas deployed out on the front lines of programming. Hats off to iNTERFACEWARE.
5 Replies to “Domain specific programming experience”
Comments are closed.
Maybe you should also look at this: http://www.jetbrains.com/mps/
Perhaps MPS can be used to build new programming experiences, but I see its main goal as generating the standard Eclipse-like IDE experience for custom languages.
MPS can call me when it can build Scala or Haskell from the ground up.
Can’t we just have domain specific plugins?
Domain-specific plugins seem great to me, but they often have a much smaller degree of useful integration that built-in features. This is probably because many plugin systems don’t make cross-plugin integration very easy, and it requires solving the problem of graceful degradation in the event that P can integrate with Q, but Q is not installed. Ideally, plugin systems could improve to make these things easier, but if you had a domain in mind for which you had a number of integratable plugins, you could always just combine the plugins into one larger plugin, as long as you had access to all the plugins’ source code.