4 ms·

Don't be so quick to discount DSLs. Sure, you don't want a half-baked DSL when some simple imperative code would do. But if you watch your API evolve into an

Don't be so quick to discount DSLs. Sure, you don't want a half-baked DSL when some simple imperative code would do. But if you watch your API evolve into an algebra and then don't formalize it with a DSL you might be leaving powerful tools for understanding on the table. A poor-fitting language is terrible for abstract thinking, on the other hand an internally-consistent and domain appropriate language can unlock new ways of looking at problems. I'd highly recommend Martin Fowler's work on DSLs to see how you can apply these techiques to large projects.

jacobr1 3y ago
A related notion is that you need strong, well-thought out, and when the system is changing, regularly refactored abstractions. You might not need a DSL but your class/type/trait designs needs to be sane, your API needs to be solid, etc ... DDD principles are key here.
- couchand 3y ago
  Yes, eat your vegetables! A question of philosophy: If you have all that, don't you already have a DSL, using a deep embedding in the host language?
  - seanc 3y ago
    I certainly think so. Or at least I find it very helpful to think about interface design that way. It's DLS's all the way down.
  - jimbokun 3y ago
    Yes, but the language in which you create your framework can do a lot of the heavy lifting. For example, if your main interface is a REST API, there is a large body of knowledge of best practices, educational resources, and existing tools for interacting with it. With a new DSL, you need to create all of that yourself.
    - couchand 3y ago
      The point I (and it seems several others here) are trying to make is that your API already is a DSL, the question is just whether it's a good one or a bad one. A good one is internally consistent so that users have predictability when writing and reading usage. A good one uses the minimum number of distinct elements required for the problem domain. A good one lets the user focus on what they're trying to do and not how they need to do it. The principles apply regardless of interface. Physical device, software UI, API, DSL, argument over HN, it's all a continuum.
wredue 3y ago
The problem a lot of people have with DSLs is… well, just look at a prime example: SAS. If you’re an experienced programmer coming in to SAS, your vocabulary for the next LONG time is going to consist primarily of “What The Fuck is this shit?!?”
- smallnamespace 3y ago
  What do you mean? Computations very naturally organize into batches of 40 cards each.
- purist33 3y ago
  I hated SAS with a passion when I was forced to work with it for 2 years. One of the biggest problems I faced was, it would take me a long time to find out if something was doable or almost impossible in that language. It wanted to be more than just SQL, but the interoperability with other languages was awful, we couldnt even work with it like SQLite.
rugina 3y ago
Given that the GitHub repo is almost three years old, I expect Martin Fowler to already have Dada Patterns, Refactoring in Dada, Dada Distilled, Dada DSL and Dada Best Practices ready to publish.
jimbokun 3y ago
Yes, but then you need to be able to market your DSL and get buy-in. Otherwise you will forever be just a team of one. And then need to sell to all the stakeholders of the project the idea of trusting one person for all the development. So in addition to the skill of creating a DSL, you need the skills of thoroughly documenting it, training other people to use it, creating tools for it, and explaining the benefits in a way that gets them more excited than just using an existing Boring Old Programming Language. Which is certainly possible. You can get non developers excited if they can use it for answering their own questions or creating their own business rules, for example. But it's a distinct skill set from cranking out code to solve problems. It requires a strong understanding of the UX (or DX) implications of this new language.
- travisjungroth 3y ago
  I’m of the mindset that API and DSL are more of a continuum than categories. As soon as you write your first abstraction, you’re making a little language. In the same way, what you listed isn’t a distinct skill set from cranking out code to solve problems. What happens is those skills are now levered. Not the good vibes “leveraged”. I mean in the “impact to success and failure is 100x baseline” sense. If those skills are in the red, you get wiped out.
- couchand 3y ago
  Every word you wrote is true. It's all still true if you replace "DSL" with any project and "Boring Old Language" with the competitor. This is the stopping at 90% problem somebody just posted a link to in another thread. edit: https://austinhenley.com/blog/90percent.html https://austinhenley.com/blog/90percent.html
  - jimbokun 3y ago
    No, for Boring Old Language other people have already solved those problems for you.
    - couchand 3y ago
      Regardless of how supposedly non-controversial each technical design decision is, you will find that the entire scope of them never is. So you will always be working to bring people along to your design choices and help them understand the (relative) value, or risk forever languishing as the sole contributor. You don't get buy-in with technology, you get buy-in with ideas.
librasteve 3y ago
amen to this … i recommend thinking about your problem in terms of effective data structures and then apply even a very simple DSL to handle access and transformations … fwiw the built in Grammars and Slang support in raku https://docs.raku.org https://docs.raku.org are fantastic tools for this job.

jacobr1 3y ago

A related notion is that you need strong, well-thought out, and when the system is changing, regularly refactored abstractions. You might not need a DSL but your class/type/trait designs needs to be sane, your API needs to be solid, etc ... DDD principles are key here.

couchand 3y ago
Yes, eat your vegetables! A question of philosophy: If you have all that, don't you already have a DSL, using a deep embedding in the host language?
- seanc 3y ago
  I certainly think so. Or at least I find it very helpful to think about interface design that way. It's DLS's all the way down.
- jimbokun 3y ago
  Yes, but the language in which you create your framework can do a lot of the heavy lifting. For example, if your main interface is a REST API, there is a large body of knowledge of best practices, educational resources, and existing tools for interacting with it. With a new DSL, you need to create all of that yourself.
  - couchand 3y ago
    The point I (and it seems several others here) are trying to make is that your API already is a DSL, the question is just whether it's a good one or a bad one. A good one is internally consistent so that users have predictability when writing and reading usage. A good one uses the minimum number of distinct elements required for the problem domain. A good one lets the user focus on what they're trying to do and not how they need to do it. The principles apply regardless of interface. Physical device, software UI, API, DSL, argument over HN, it's all a continuum.

wredue 3y ago

The problem a lot of people have with DSLs is… well, just look at a prime example: SAS. If you’re an experienced programmer coming in to SAS, your vocabulary for the next LONG time is going to consist primarily of “What The Fuck is this shit?!?”

smallnamespace 3y ago
What do you mean? Computations very naturally organize into batches of 40 cards each.
purist33 3y ago
I hated SAS with a passion when I was forced to work with it for 2 years. One of the biggest problems I faced was, it would take me a long time to find out if something was doable or almost impossible in that language. It wanted to be more than just SQL, but the interoperability with other languages was awful, we couldnt even work with it like SQLite.

rugina 3y ago

Given that the GitHub repo is almost three years old, I expect Martin Fowler to already have Dada Patterns, Refactoring in Dada, Dada Distilled, Dada DSL and Dada Best Practices ready to publish.

jimbokun 3y ago

Yes, but then you need to be able to market your DSL and get buy-in. Otherwise you will forever be just a team of one. And then need to sell to all the stakeholders of the project the idea of trusting one person for all the development. So in addition to the skill of creating a DSL, you need the skills of thoroughly documenting it, training other people to use it, creating tools for it, and explaining the benefits in a way that gets them more excited than just using an existing Boring Old Programming Language. Which is certainly possible. You can get non developers excited if they can use it for answering their own questions or creating their own business rules, for example. But it's a distinct skill set from cranking out code to solve problems. It requires a strong understanding of the UX (or DX) implications of this new language.

travisjungroth 3y ago
I’m of the mindset that API and DSL are more of a continuum than categories. As soon as you write your first abstraction, you’re making a little language. In the same way, what you listed isn’t a distinct skill set from cranking out code to solve problems. What happens is those skills are now levered. Not the good vibes “leveraged”. I mean in the “impact to success and failure is 100x baseline” sense. If those skills are in the red, you get wiped out.
couchand 3y ago
Every word you wrote is true. It's all still true if you replace "DSL" with any project and "Boring Old Language" with the competitor. This is the stopping at 90% problem somebody just posted a link to in another thread. edit: https://austinhenley.com/blog/90percent.html https://austinhenley.com/blog/90percent.html
- jimbokun 3y ago
  No, for Boring Old Language other people have already solved those problems for you.
  - couchand 3y ago
    Regardless of how supposedly non-controversial each technical design decision is, you will find that the entire scope of them never is. So you will always be working to bring people along to your design choices and help them understand the (relative) value, or risk forever languishing as the sole contributor. You don't get buy-in with technology, you get buy-in with ideas.

librasteve 3y ago

amen to this … i recommend thinking about your problem in terms of effective data structures and then apply even a very simple DSL to handle access and transformations … fwiw the built in Grammars and Slang support in raku https://docs.raku.org https://docs.raku.org are fantastic tools for this job.