Rants and Raves

The original idea behind Gem was to try to design a programming language that could unify graphics (notation), execution (semantics) and modeling (structure) in the simplest way I can devise.

In the graphical realm I want to explore the idea of textual language syntax that suggests and flows into graphical representations. For example ( ) may suggest a circle or a radial layout and [ ] may suggest a box or a rectangular layout.

In the modeling realm I'm interested in the parallels between metamodels and grammatical languages (e.g. BNF) and how we can apply the insights and methods of the latter subject to the former. I'm also inspired by how EMF with a dozen or so primitive constructs (in Ecore.ecore) can tame the hugeness of UML. I'd like to search for other (meta)metamodels that are similarly simple, general and provide great leverage.

For execution all I can say is that I'll be happy when I have a model debugger and can step through a program model and watch it modify a data model (or itself).

There are some other ideas that feed into this project. They mostly amount to things that aggravate me with existing tools which I'd like to try to improve:

• Modeling tools tend to have a central diagram space and a separate area for viewing and editing "properties". Getting anything done requires a lot of mousing back-and-forth between these two areas. I'd like to try to get rid of the properties view entirely and do all editing in the diagram space.
• I think the keyboard has been greatly underutilized in modeling tools. I should be able to type in model fragments as text and have them parsed and redisplayed in whatever diagrammatic notation I'm currently using to view the model.
• A lot of modeling systems use code generation as a mechanism for tailoring their behavior. This can be good, but I'd like to resist it as long as possible. All other things being equal, I'd prefer to use host language features (such as interface implementation) to allow developers to tailor the behavior.
• The layout algorithms in graphical modeling tools rarely do what I want. And I can spend a lot of time arranging things "just right" and then be forced to start over when I need to add or remove elements from the diagram. I think there's an assumption that modelers want "freeform drawing". Actually what I want almost always is good automatic layout. I think the layout mechanism should work like a source code formatter: tweak some options (or model attributes) and then invoke the "reformat" action.

Another way I think about Gem (not the current implementation, but the Gem I'd like to get to) is as a visual/graphical programming language "done right". Visual programming languages go all the way back to Logo (maybe farther) and I've played with several of them but I've never seen one that made me feel as productive as the textual programming languages I use. I think if you polled a bunch of programmers and asked them, "will you ever prefer a graphical language over a purely text-based one?" very few would say 'yes' and many would say that it just isn't possible to have a graphical language that enhances productivity. But if you asked these same people 10 years ago, "Will you ever feel more productive in an IDE than with your toolbox of emacs/vi, compiler, debugger, formatter, ... ?" many of them would have said 'impossible' then but are very happily using Eclipse, Visual Studio, etc. today.

So things do get better, and the impossible becomes the norm. There has been a renaissance in programming language design over the last several years - which I think is great. But the vast majority are textual languages. Let's explore the second dimension. Now is not too early to be thinking about a viable graphical programming language. I don't know if Gem will be that language (it certainly isn't close yet), but that's what I think it wants to be. And even if it fails to become a viable language, it will be a success if it sheds new light on any of the ideas and aggravations discussed above.