4 ms·
I'm currently developing a DSL. I definitely agree with what you're saying. Domain and technical expertise are needed in abundance. Writing a spec is HARD.
by scottious 11y ago
I'm currently developing a DSL. I definitely agree with what you're saying. Domain and technical expertise are needed in abundance. Writing a spec is HARD. It takes a certain perseverance to learn good parser design (I've written a great parser generator and I still feel inadequate in this area sometimes).
DSLs are costly. My concern is that the cost will outweigh the benefit and people won't like it and we'll be suck with it. My hope is that it'll stabilize and be expressive enough to fit everybody's needs.
Did you ever write a DSL used in a production environment? How complex was the DSL, more declarative or closer to a general purpose language?
- sklogic 11y ago> Writing a spec is HARD. Chances are that you're severely over-engineering it. Just take the English specification for any particular problem your DSL is supposed to solve and slightly tweak it into looking like a formal language. That's it. Extremely easy with a bit of practice.
- ExpiredLink 11y agoYou have no idea.
- sklogic 11y agoYes, tell me more. I build eDSLs professionally. You can take a look at some of the stuff I'm building: https://github.com/combinatorylogic https://github.com/combinatorylogic
- ExpiredLink 11y agoBut where is the domain in your Domain Specific Languages? You built SLs but not DSLs.
- sklogic 11y agoIn this case domain itself is language construction: I built a system of DSLs that make implementing any other DSLs easy. And I am using this and the other similar toolchains (like Racket) to build DSLs for a very wide range of domains.
- ExpiredLink 11y agoI never wrote a DSL for a production environment. Once I wrote a DSL that allowed users to script an existing API for testing purposes. In my experience e.g. EDI and ISO specifications and protocols are also good DSLs.