My remark was just an old Java joke I repurposed for Ant!

"Java is a DSL for taking large XML files and converting them to stack traces." -Andrew Back

https://www.reddit.com/r/programming/comments/eaqgk/java_is_...

But in all seriousness:

OpenLaszlo used XML with embedded JavaScript in a way that let you extend XML by defining your own tags in XML+JavaScript. I've done a lot of work with it, and once you make your peace with XML (which seemed like a prudent thing to do at the time), it's a really productive enjoyable way to program! But that's more thanks to the design of OpenLaszlo itself, rather than XML.

https://en.wikipedia.org/wiki/OpenLaszlo

OpenLaszlo (which was released in 2001) inspired Adobe Flex (which was released in 2004), but Flex missed the point of several of the most important aspects of OpenLaszlo (first and foremost being cross platform and not locking you into Flash, which was the entire point of Flex, but also the declarative constraints and "Instance First Development" and the "Instance Substitution Principal", as defined by Oliver Steele).

https://en.wikipedia.org/wiki/Apache_Flex

https://blog.osteele.com/2004/03/classes-and-prototypes/

The mantle of constraint based programming (but not Instance First Development) has been recently taken up by "Reactive Programming" craze (which is great, but would be better with a more homoiconic language that supported Instance First Development and the Instance Substitution Principle, which are different but complementary features with a lot of synergy). The term "Reactive Programming" describes a popular old idea: what spreadsheets had been doing for decades.

OpenLaszlo and Garnet (a research user interface system written by Brad Myers at CMU in Common Lisp) were exploring applying automatic constraints to user interface programming. Garnet started in the early 1990's. Before that, Ivan Sutherland's Sketchpad explored constraints in 1963, and inspired the Visual Geometry Project in the mid 1980's and The Geometer's Sketchpad in 1995.

https://en.wikipedia.org/wiki/Reactive_programming

http://www.cs.cmu.edu/afs/cs/project/garnet/www/garnet-home....

https://en.wikipedia.org/wiki/Sketchpad

http://math.coe.uga.edu/TME/Issues/v10n2/4scher.pdf

https://en.wikipedia.org/wiki/The_Geometer%27s_Sketchpad

I've written more about OpenLaszlo and Garnet:

What is OpenLaszlo, and what's it good for?

https://web.archive.org/web/20160312145555/http://donhopkins...

>Declarative Programming: Declarative programming is an elegant way of writing code that describes what to do, instead of how to do it. OpenLaszlo supports declarative programming in many ways: using XML to declare JavaScript classes, create object instances, configure them with automatic constraints, and bind them to XML datasets. Declarative programming dovetails and synergizes with other important OpenLaszlo techniques including objects, prototypes, events, constraints, data binding and instance first development.

Constraints and Prototypes in Garnet and Laszlo
https://web.archive.org/web/20160405015129/http://www.donhop...

>Garnet is an advanced user interface development environment written in Common Lisp, developed by Brad Meyers (the author of the article). I worked for Brad on the Garnet project at the CMU CS department back in 1992-3.

https://news.ycombinator.com/item?id=17360883

DonHopkins on June 20, 2018 | parent | favorite | on: YAML: probably not so great after all (2017)

>That was also one of the rationales behind TCL's design.
John Ousterhout explained in one of his early TCL papers that, as a "Tool Command Language" like the shell but unlike Lisp, arguments were treated as quoted literals by default (presuming that to be the common case), so you don't have to put quotes around most strings, and you have to use punctuation like ${}[] to evaluate expressions.

>TCL's syntax is optimized for calling functions with literal parameters to create and configure objects, like a declarative configuration file. And it's often used that way with Tk to create and configure a bunch of user interface widgets.

>Oliver Steel has written some interesting stuff about "Instance-First Development" and how it applies to the XML/JavaScript based OpenLaszlo programming language, and other prototype based languages.

>Instance-First Development: https://blog.osteele.com/2004/03/classes-and-prototypes/

>The equivalence between the two programs above supports a development strategy I call instance-first development. In instance-first development, one implements functionality for a single instance, and then refactors the instance into a class that supports multiple instances.

>[...] In defining the semantics of LZX class definitions, I found the following principle useful:

>Instance substitution principal: An instance of a class can be replaced by the definition of the instance, without changing the program semantics.

>In OpenLaszlo, you can create trees of nested instances with XML tags, and when you define a class, its name becomes an XML tag you can use to create instances of that class.

>That lets you create your own domain specific declarative XML languages for creating and configuring objects (using constraint expressions and XML data binding, which makes it very powerful).

>The syntax for creating a bunch of objects is parallel to the syntax of declaring a class that creates the same objects.

>So you can start by just creating a bunch of stuff in "instance space", then later on as you see the need, easily and incrementally convert only the parts of it you want to reuse and abstract into classes.

>What is OpenLaszlo, and what's it good for?
https://web.archive.org/web/20160312145555/http://donhopkins...

>Constraints and Prototypes in Garnet and Laszlo: https://web.archive.org/web/20160405015129/http://www.donhop...

https://news.ycombinator.com/item?id=11232154

>DonHopkins on Mar 6, 2016 | parent | favorite | on: Garnet – a graphical toolkit for Lisp

>Yay Garnet! ;) I worked on Garnet with Brad Myers at CMU, on the PostScript printing driver. Brad is really into mineral acronyms, and I came up with an acronym he liked: "GLASS: Graphical Layer And Server Simplifier".

>Garnet had a lot of cool ideas in it, especially its constraints and prototype based object system.

>A few years ago I wrote up a description of a similar system called OpenLaszlo, and how OpenLaszlo's constraint system compared with Garnet's constraint system. Garnet had a lazy "pull" constraint system, while Laszlo had an event/delegate based "push" system. Each used a compiler to automatically determine the dependencies of constraint expressions.

>Constraints and Prototypes in Garnet and Laszlo

>https://web.archive.org/web/20160405015129/http://www.donhop...

>The problem we ran into with supporting PostScript with Garnet is that we wanted to use Display PostScript, but Garnet was using CLX, the Common Lisp X Protocol library which was of course totally written purely in Lisp.

>Of course CLX had no way to use any client side libraries that depended on XLib itself. I'd steer clear of using anything that depends on CLX for anything modern. (Does CLX still even exist?)

>Brad Myers produced "All the Widgets," which must have some Garnet demos in there somewhere! [1]

>[1] All the Widgets, sponsored by the ACM CHI 1990 conference, to tell the history of widgets up until then: https://www.youtube.com/watch?v=9qtd8Hc90Hw

mpweiher on Mar 6, 2016 [-]

>> https://web.archive.org/web/20160405015129/http://www.donhop...
"Constraints are like structured programming for variables"

>Love it! Having been very interested in constraint programming and also dabbled a bit here and there[1][2][3], what do you think is holding back constraint programming?

>[1] http://2016.modularity.info/event/modularity-2016-mvpapers-c...

>[2] http://blog.metaobject.com/2014/03/the-siren-call-of-kvo-and...

>[3] http://blog.metaobject.com/2015/09/very-simple-dataflow-cons...

DonHopkins on Mar 6, 2016 [-]

>> what do you think is holding back constraint programming?

>All the constraints. ;)

>As you mentioned, there are tricky two-way mathematical constraints, like Sutherland's Sketchpad [1] and descendants [2], and Gosling's PhD Thesis [3], where the system understands the constraint expressions mathematically and transforms them algebraically.

>[1] Ivan Sutherland's Sketchpad: https://en.wikipedia.org/wiki/Sketchpad

>[2] Geometer's Sketchpad: https://en.wikipedia.org/wiki/The_Geometer%27s_Sketchpad

>[3] Algebraic Constraints; James Gosling; CMU CS Department PhD Thesis: http://digitalcollections.library.cmu.edu/awweb/awarchive?ty...

>And there are simpler one-way data flow constraints like Apple's KVO notification [4], Garnet's KR based constraints [5], and OpenLaszlo's event/delegate based constraints [6].

>[4] Introduction to Key-Value Observing Programming Guide: https://developer.apple.com/library/mac/documentation/Cocoa/...

>[5] KR: Constraint-Based Knowledge Representation: https://docs.google.com/viewer?url=http%3A%2F%2Fwww.cs.cmu.e...

>[6] Oliver Steel: Instance-First Development: http://blog.osteele.com/posts/2004/03/classes-and-prototypes...

>As you pointed out, KVO constraints simply say that object.x = otherObject.y, so there's not much to them.

>I think one thing holding back constraint programming is that they require an interpreter or compiler to understand them, or the programmer to write code in a constrained syntax.

>Garnet's KR constraints are written as Lisp expressions implemented by Lisp macros, that parse the expressions and recognize certain expressions like "gvl" for "get value", and named path expressions. KR wires up the dependency graph based on that information, and marks the constraint as invalid if any of the links along the dependency path change, as well as when any of the final values the expressions reference change. But it doesn't understand the mathematical expressions themselves. At the time I was working on it, it didn't know hot to figure out which branches of conditional expressions mattered, so it would assume it depended on everything in the expression. (i.e. like the C expression "size = window.landscape ? parent.width : parent.height" -- if window.landscape is true, it depends on parent.width, else it depends on parent.height, but ). It only recalculates the constraint values lazily when you read them. ("pull" constraints).

>OpenLaszlo constraints are written as JavaScript expressions that the OpenLaszlo compiler parses, and it creates some JavaScript data and hidden methods behind the scenes that go along with the class, which are used at runtime to keep track of all the dependencies. You don't have to use a special expressions in constraints to read values, but you do have to use object.setValue("key", value) to write values. (This was because OpenLaszlo was targeting the Flash runtime, and that was the most efficient trade-off, since Flash didn't support property setters like modern JavaScript does.)

>OpenLaszlo constraints used a "push" model of propagating all dependent changes forward when you called "setValue", because that was the best trade-off at the time for speed and usability and how it was intended to be used. But with getters and setters you could implement a more convenient constraint system that didn't put so many constraints on the programmer and how you use them.