Replacing Sawzall – a case study in domain-specific language migration | Hacker News Reader

Replacing Sawzall – a case study in domain-specific language migration

unofficialgoogledatascience.com

47 pointscnbuff4105 comments

Expected this to be an analysis of the replacement of the "Sawzall®" trademark name with the generic "Reciprocating saw". Milwaukee used to be the only manufacturer, now everybody makes one, and in cordless versions too. It would be an interesting language study to analyze the construction and demolition domains to find out at what rate do people stop calling them Sawzalls, and how is this age or experience dependent?

And no, Googler, they're rarely used for cutting regular logs. Green wood is likely to pinch the blade and cutting will be slow. That's what chainsaws are for. Sawzalls are useful for two reasons: The blades are cheap, thin, flexible, and replaceable, so they're ideal for demolition. Need to remove a sill plate that's been nailed to the concrete? Push the sawzall blade under it and cut the nails flush. Need to remove a header to resize a window or door? Just cut it with the sawzall. Also, the blade is short, so you can cut curves in thin material. Need to cut a profile out of that installed gypsum board (language migration - was "Drywall®") or cement board? Skip the hand saw and use the Reciprocating Saw/Sawzall.

What would be further interesting is at what rate do these trends appear and disappear in other, faster-moving domains - for example, Skype still has an advantage because some people use it as a generic word for video chat. How does this affect Apple, Google, Snapchat, WhatsApp, and other providers? How long does this last? Do people still "check in" to CVS/SVN when they really mean they "git commit"?

"At Google, most Sawzall analysis has been replaced by Go. ... To ease the process of migrating from Sawzall, we’ve developed a set of Go libraries that we call Lingo (for Logs in Go)."

The eternal conflict between domain specific languages and libraries in general purpose languages.

...and the resulting eternal search for adaptable general purpose programming languages to resolve the conflict. See Smalltalk-72 (too much), Smalltalk-76 (keyword syntax, nice compromise for making APIs DSL-ish), Ruby (hackable, but nasty), Grace's generalized method names (looks pretty awesome!)...

Grace's method names allow one to say:

    circle.at(x,y) radius(5) fill("solid")

where in Python one might say:

    circle.at(x,y, radius=5, fill="solid")

Objective C also allows multipart method names that help document the arguments.

For you young whippersnappers, this idea goes back over half a century to Algol-60 where the commas that delimit parameters to functions can be optionally replaced by ") text: (". So our procedure call in Algol-60 could be written:

    draw(circle) at: (x,y) radius: (5) fill: (1.0)

or as:

    draw(circle, x, y, 5, 1.0)

Well, Objective-C's message names came from Smalltalk:

    context circleWithFill:'solid' at:x@y radius:5.

These keyword messages actually go a long way towards bridging the gap between API and DSL.

What Grace does is based on this approach, but goes significantly beyond it in closing the gap further by allowing the parameter parts to be regular languages. So as a somewhat silly example you could have a single method that draws circles of the same size and fill at many different locations:

    context circlWithFill:'solid' at:20@30 at:30@30 at: 100@20 radius:5.

Depending on the definition of the method, the 'at:' part could be repeated 0-n times. It's pretty amazing.

https://michael.homer.nz/Publications/DLS2015/paper.pdf

Reply on news.ycombinator.com