[tombert]

> Declarative DSLs are great when your problem is simple, but don't scale.

Can you define "don't scale"? I keep hearing that but I feel like I've made relatively complex models with declarative DSLs and from a "writing code" perspective I do think they scale perfectly fine. I'll grant that performance gets a little bad, generally I end up having greatly reduce the face number when I'm working and bump it up when doing a final render.

[ajross]

Inevitably you want to do something that the declarators in your language don't support. Like, in this space you might have a parametrization function for a model (like... "swiss cheese" maybe) which needs to decide on a number of CSG child nodes ("holes") that is randomly generated. Your DSL (OpenSCAD) can't do that because it has a fixed graph. So now you need to write python to generate your DSL code in two separate layers. It would be simpler to have just started with python to begin with.

This pattern repeats again and again[1] every time someone tries to push a DSL for complicated problems. DSLs are a great way to address the boilerplate and copying and tedium of working with bad frameworks in imperative languages. But they don't work once you really get rolling, and you end up in some kind of imperative hell anyway.

Declarative programming as an API design style is hugely valuable and great. Declarative programming languages as an implementation choice are IMHO a bad smell.

[1] If you think about it, this is really just another corrolary of Greenspun's Tenth Rule.

[tombert]

Fair enough; it breaks some functional purity but in Bowler Studio you can have a mostly-scad-like DSL but you have access to the typical Clojure `rand` function. I'm pretty sure I could make that Swiss cheese pattern you described.