| hiya jackson :) yea… that's a longer discussion. I've been influenced on this by some coworkers (cf. http://www.hammerlab.org/2015/01/21/introducing-ketrew-0-0-0...) and conference talks (including one at NEScala 2wks ago, https://github.com/nescalas/proposals-2017/blob/master/long-... ); one way to think of it is that there are blurry lines between a DSL and any plain old API… they're kind of the same idea, though conventionally DSLs have tended to involve more punctuation marks, and I agree that that can be taken too far, and that SBT did in fact take it too far in the past! On the other hand, XML with a given schema is a kind of DSL as well, and where it's possible to make e.g. Scala DSLs overly concise to the point of inscrutable trickiness, XML APIs are frequently considered to be inscrutably verbose, as we've all heard and experienced ad nauseum. However, given Scala's powerful type-checker and flexible syntax, more sane middle grounds can be explored. Maybe a less controversial example in SBT is the "/" operator for constructing filesystem paths (https://github.com/sbt/sbt/blob/v0.13.13/util/io/src/main/sc...), which I incidentally just mimicked in a java-nio-Path-wrapper library this past weekend (https://github.com/hammerlab/path-utils/blob/1.0.2/src/test/...). The alternative here is Java's Path.resolve(), which is a bit clunky to say the least. Also some of the JSON-DSLs we dealt with at 4sq come to mind as nice bits of ad-hoc syntax that still benefit from all of Scala's type-checking wondrousness :) (edit: fixed broken link) |