> What DSLs might someone make today? Oh, but there are SO many! These two super-categories I am very fond of: - Query languages - Infrastructure specificat

> What DSLs might someone make today? Oh, but there are SO many! These two super-categories I am very fond of: - Query languages - Infrastructure specification languages Here are some concrete examples: GraphQL: An API query language: https://graphql.org/ https://graphql.org/ jq: A JSON command-line processor: https://stedolan.github.io/jq/ https://stedolan.github.io/jq/ HCL: A DSL for expressing Terraform assets: https://developer.hashicorp.com/terraform/cdktf/concepts/hcl-interoperability https://developer.hashicorp.com/terraform/cdktf/concepts/hcl... Troll: A DSL for expressing dice roll simulations: http://hjemmesider.diku.dk/~torbenm/Troll/ http://hjemmesider.diku.dk/~torbenm/Troll/ fvg: Functional Vector Graphics: https://github.com/lemmih/fvg https://github.com/lemmih/fvg Kleenex: Optimal regex-based stream processor: https://kleenexlang.org/ https://kleenexlang.org/ Futhark: High-performance purely functional data-parallel array programming: https://futhark-lang.org/ https://futhark-lang.org/ > And when should they be libraries instead? A friend recently told me that DSLs (stand-alone) and eDSLs (embedded in an existing language) have the main difference that DSLs are overgrown configuration files, and eDSLs are overgrown libraries. I'd say: When you want to call your DSL from more than one programming environment, it is good to have an abstract representation that transcends one particular syntax-tree definition. A library is good until then.