One of the most interesting points he made about DSLs was that they can enable people who don't think of themselves as programmers to program. His example was Cascading Style Sheets (CSS). Web designers don't usually consider themselves to be programmers, but they are usually proficient in writing style sheets. Since CSS is a language that is targeted for a very specific purpose (describing presentation of HTML pages), it doesn't "feel" like a programming language. Yet that's what it is. It's not a turing-complete language, but that's one of its strengths.
DSLs, in fact, aren't limited to computer languages; they can be relevant to language in general. Martin's example of this was the jargon required to order your favorite, multi-adjective drink from Starbucks. A Grande, Non-Fat, Vanilla, Decaf Frappuccino with Whip doesn't have much meaning outside of Starbucks, yet it is a concise way to communicate your specific drink preference to the barista. (By the way, this is not my favorite Starbucks
drink!)
It should come as no surprise, then, that directions for any knitting pattern use terminology from an informal DSL. There are relatively standard abbreviations for knit, purl, slip, etc. Even though a legend is usually provided with the pattern, most knitters do not need to refer to it to understand that, for instance, k2tog
means "knit the next two stitches together through their leading loops, creating one stitch out of two." We have to keep this in mind when creating a computer-based DSL for knitting patterns. Since there is already a DSL for expressing patterns, we should make our DSL look as much like the existing one as possible.
I've run across several knitting applications that claim to have "pattern-like" syntax, but in reality its expression is significantly hampered by the underlying programming language. This from the
Knitter project, for instance, still feels very much like a programming language:
sk fix(-3,0,0) co 7 fix(3,0,0)
turn k 8
turn k 2 k2tog k 2
turn toEndk
It would be fairly unreasonable to expect designers to express their patterns in this format.
This knitting chart generator has much clearer syntax, yet the square brackets around many instructions make this a bit awkward:
[k]8
[k]2,[k2tog]2,[k]2
k,k,k,k,k,k,k,k
The tool makes this somewhat easier to deal with by providing a graphics for create the chart. However, point-and-click solutions are traditionally not very fast. What if I were transcribing row-by-row instructions out of a book? In that case I can use type in the syntax, but now I'm hampered by the square brackets. What if the pattern were published on a web site? I would want to copy/paste the directions, but short of coming up with a fancy regular expression, I would have to do this by hand.
Now, I'm not meaning to knock the work of the Knitter or Orangellous folks. They've done a lot of work to create their software, and I'm sure their programs will provide (or already have provided) value to the knitting community. And, to be fair, the usability of their syntax was not top priority. However, they may want to consider that an awkward syntax has the potential to get in the way of adoption.
You may be wondering how close you can get to the look and feel of a real pattern while still writing something that a computer can understand. If you've been reading this blog, you can probably guess. :)
You could write the above directions like this in the KnitML Expression Language (KEL):
co 8 sts
Row 1: k8
Row 2: k2, k2tog twice, k2
Row 3: k to endThis is indistinguishable from a real pattern. Yes, there is a bit of syntactic baggage to set up the pattern, and I need to take a closer look at improving some of it. In the interest of full disclosure, the full pattern would look like this:
Pattern {
Directions {
co 8 sts
Row 1: k8
Row 2: k2, k2tog twice, k2
Row 3: k to end
}
}
It's also worth nothing that KEL patterns are not KnitML patterns, per se. Rather, they translate into KnitML patterns. KnitML is an application of XML, which represents a knitting pattern's canonical form. A canonical form is very important as an interchange format between software components, because the software processing is greatly simplified. Having a DSL sit on top of the canonical form gives us the best of both worlds. We get pattern readability up front, while programmers don't have to write software for every conceivable expression difference.
To put it another way, KEL allows you to write patterns in a familiar way. In turn, it translates that into an internal standard that software of all kinds will rally around. Then any knitter can render the KnitML pattern in a form that's most familiar to the way they read patterns. Computer DSLs don't have to be syntactically perfect for them to be usable, but they should be clear enough to be meaningful and easy to use. The more meaning their syntax conveys, the less intimidating they will seem to the average user. Programmers can keep "computery" languages to themselves.
[ add comment ] ( 3 views ) | [ 0 trackbacks ] | permalink
Archives
