{"id":31,"date":"2005-08-19T11:57:51","date_gmt":"2005-08-19T16:57:51","guid":{"rendered":"http:\/\/alarmingdevelopment.org\/?p=31"},"modified":"2005-08-19T11:58:45","modified_gmt":"2005-08-19T16:58:45","slug":"domainobject","status":"publish","type":"post","link":"https:\/\/alarmingdevelopment.org\/?p=31","title":{"rendered":"domain\/object"},"content":{"rendered":"<p>Dynamic Aspects has published their upcoming <a href=\"http:\/\/www.dynamicaspects.com\/event\/oopsla2005\/op07-perera.pdf\">OOPSLA presentation<\/a> of domain\/object, the language underlying their Java IDE. There is a remarkable correspondence between their ideas and my own. This makes reviewing their paper a difficult proposition: it would be easy to nitpick over differences; but it would be equally easy to falsely read my own ideas between the lines of theirs.<!--more--><\/p>\n<p>Their primary objective is a fancy Java IDE called domain\/j that supports what I call <i>semantic editing<\/i>: direct manipulation of an abstract, non-syntactic model of a program. The IDE is implemented as an incremental bidirectional transformation between the syntactic and semantic structure of a Java program. The incrementality provides the same abilities as Eclipse&#8217;s incremental compilation: being able to get live semantic feedback while editing syntax. It is the bidirectional nature that is novel, allowing semantic level edits (which they call <i>micro-refactorings<\/i>) to be transformed back into syntax changes. This reverse transformation allows direct manipulation of the program at the semantic level.<\/p>\n<p>Domain\/object is the language that implements this bidirectional transformation. It provides facilities such as persistence, versioned execution, transactions, and bidirectional execution. At base it is a LISP-ish data-flow language embedded syntactically within Java. Eclipse internally implements some of the same capabilities, albeit in a more restricted form. For example, bidirectional transformations on the internal semantic model are supported through the mechanism of &quot;live lists&quot;. Eclipse has internal persistence and versioning models as well. The point of domain\/j is to provide these capabilities in a simpler and more general fashion by building them into a language, avoiding the massive complexity of the Eclipse API&#8217;s. Domain\/j is essentially a Domain Specific Language for building IDE&#8217;s.<\/p>\n<p>Domain\/object is supposed to have a &quot;live&quot; execution model like Subtext, in which all code is always executing, eliminating the distinction between compile-time and run-time. But I do not understand how that is achieved, since it is embedded within Java and thus must be compiled prior to execution. Perhaps this is a meta-circular thing, whereby their Java IDE is lively interpreting the domain\/object code. This would imply their IDE&nbsp;makes Java fully live, a significantly larger accomplishment than they seem to be claiming.<\/p>\n<p>I wholeheartedly agree with the grand strategy they call &quot;semantic computing&quot;, which (reading between the lines now) is what I call <a href=\"http:\/\/alarmingdevelopment.org\/?p=9\">Structure Oriented Programming<\/a>. The idea is to build systems through bidirectional transformations, combinations, and queries between different sorts of structures. It would be nice to construct typical business applications as a bidirectional transformation between a UI and a database. This is the kind of technology needed by <a href=\"http:\/\/martinfowler.com\/articles\/languageWorkbench.html\">DSL workbenches<\/a> and <a href=\"http:\/\/martinfowler.com\/articles\/mdaLanguageWorkbench.html\">Model Driven Architecture<\/a>.<\/p>\n<p>Where we disagree (nitpicking now) is on how conceptually elegant the language needs to be. I have been exploring along the same lines for a long time, but have so far found it to contain nasty semantic black holes that require ugly ad-hocery to avoid. I detect hints of the same problems in their paper, for example in handling the indeterminacy of reverse execution, and in handling the impact of asynchronous side-effects on the data-flow model of execution. I imagine they can come up with workarounds in the context of their IDE implementation, but I am less sure that the result is a clean and simple language that can be widely applied elsewhere. Perhaps they are clever enough to solve these problems &#8211; I look forward to seeing the details. Or perhaps I am just too finicky, and these are not actually problems in practice.<\/p>\n<p>My approach to the problems of mutable state and side-effects is to develop a model of computation that treats time and change in a more tractable way. My intuition about bidirectional execution is that it should not be a universal property of the language, but of a select set of higher-level constructions. Benjamin Pierce has done some <a href=\"http:\/\/www.cis.upenn.edu\/%7ebcpierce\/papers\/newlenses-popl.pdf\">work<\/a> that may be relevant.<\/p>\n<p>In summary, Dynamic Aspects is doing some interesting and potentially important work. I am happy to find other people of like mind, and I wish them the best of luck. The one piece of advice I would give them is to tone down their claims, which are so dramatic as to invite skepticism. I look forward to attending their presentation at OOPSLA.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Dynamic Aspects has published their upcoming OOPSLA presentation of domain\/object, the language underlying their Java IDE. There is a remarkable correspondence between their ideas and my own. This makes reviewing their paper a difficult proposition: it would be easy to nitpick over differences; but it would be equally easy to falsely read my own ideas &hellip; <\/p>\n<p class=\"link-more\"><a href=\"https:\/\/alarmingdevelopment.org\/?p=31\" class=\"more-link\">Continue reading<span class=\"screen-reader-text\"> &#8220;domain\/object&#8221;<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[4],"tags":[],"class_list":["post-31","post","type-post","status-publish","format-standard","hentry","category-reviews"],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/pfEnU-v","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/alarmingdevelopment.org\/index.php?rest_route=\/wp\/v2\/posts\/31","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/alarmingdevelopment.org\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/alarmingdevelopment.org\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/alarmingdevelopment.org\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/alarmingdevelopment.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=31"}],"version-history":[{"count":0,"href":"https:\/\/alarmingdevelopment.org\/index.php?rest_route=\/wp\/v2\/posts\/31\/revisions"}],"wp:attachment":[{"href":"https:\/\/alarmingdevelopment.org\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=31"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/alarmingdevelopment.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=31"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/alarmingdevelopment.org\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=31"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}