Our great sponsors
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
> 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/
jq: A JSON command-line processor: https://stedolan.github.io/jq/
HCL: A DSL for expressing Terraform assets: https://developer.hashicorp.com/terraform/cdktf/concepts/hcl...
Troll: A DSL for expressing dice roll simulations: http://hjemmesider.diku.dk/~torbenm/Troll/
fvg: Functional Vector Graphics: https://github.com/lemmih/fvg
Kleenex: Optimal regex-based stream processor: https://kleenexlang.org/
Futhark: High-performance purely functional data-parallel array programming: 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.
> 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/
jq: A JSON command-line processor: https://stedolan.github.io/jq/
HCL: A DSL for expressing Terraform assets: https://developer.hashicorp.com/terraform/cdktf/concepts/hcl...
Troll: A DSL for expressing dice roll simulations: http://hjemmesider.diku.dk/~torbenm/Troll/
fvg: Functional Vector Graphics: https://github.com/lemmih/fvg
Kleenex: Optimal regex-based stream processor: https://kleenexlang.org/
Futhark: High-performance purely functional data-parallel array programming: 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.
> 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/
jq: A JSON command-line processor: https://stedolan.github.io/jq/
HCL: A DSL for expressing Terraform assets: https://developer.hashicorp.com/terraform/cdktf/concepts/hcl...
Troll: A DSL for expressing dice roll simulations: http://hjemmesider.diku.dk/~torbenm/Troll/
fvg: Functional Vector Graphics: https://github.com/lemmih/fvg
Kleenex: Optimal regex-based stream processor: https://kleenexlang.org/
Futhark: High-performance purely functional data-parallel array programming: 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.
> 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/
jq: A JSON command-line processor: https://stedolan.github.io/jq/
HCL: A DSL for expressing Terraform assets: https://developer.hashicorp.com/terraform/cdktf/concepts/hcl...
Troll: A DSL for expressing dice roll simulations: http://hjemmesider.diku.dk/~torbenm/Troll/
fvg: Functional Vector Graphics: https://github.com/lemmih/fvg
Kleenex: Optimal regex-based stream processor: https://kleenexlang.org/
Futhark: High-performance purely functional data-parallel array programming: 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.
Related posts
- What downsides exist to Futhark? Seems almost too good to be true?
- GPU Programming: When, Why and How?
- Functional GPU programming: what are alternatives or generalizations of the idea of "number of cycles must be known at compile time"?
- The Futhark Programming Language: Functional Array Programming in CUDA
- Achieving High-Performance the Functional Way