3 ms·

DSLs are usually written for domains where the procedural style has dominated for a while already and there’s a concrete set of concepts that have been well res

DSLs are usually written for domains where the procedural style has dominated for a while already and there’s a concrete set of concepts that have been well researched. So I believe your point is relatively useless: for example, one of the use-cases of a DSL is one’s ability to change the program at run-time , having run time predictions and also the proof of termination - all of which are a sign of a well-behaved product from the customer’s point of view.

kerkeslager 9y ago
The problem with the claims you're making about DSLs is you're not backing up anything you say with concrete examples where the implementation cost of the DSL is actually worth it. You're not responding to my point. > for example, one of the use-cases of a DSL is one’s ability to change the program at run-time , having run time predictions and also the proof of termination Returning the program as a closure with different values closed at runtime achieves the same theoretical benefit and is supported by a wide variety of popular languages with no cost of implementing the syntax.
- heavenlyblue 9y ago
  It does not, however - allow me to re-implement the methods based on the values passed into them. The greatest example of this is SQL: it takes the set of statements and transforms them into a set of steps a database needs to run in order to give you a result (and there are many ways of doing so). So essentially we end up with an optimisation problem that has to be solved (and many problems in computing are the optimisation problems where the question can be answered in many different ways). You could, however - argue that you could also implement an SQL-like language with the language of your choice; but then you had just re-implemented a DSL. And the last point against you is the fact that we are currently at the point where writing plugins for the IDEs is getting more easy, so quite frankly - the overhead of writing a new DSL is becoming less of an issue.

kerkeslager 9y ago

The problem with the claims you're making about DSLs is you're not backing up anything you say with concrete examples where the implementation cost of the DSL is actually worth it. You're not responding to my point. > for example, one of the use-cases of a DSL is one’s ability to change the program at run-time , having run time predictions and also the proof of termination Returning the program as a closure with different values closed at runtime achieves the same theoretical benefit and is supported by a wide variety of popular languages with no cost of implementing the syntax.

heavenlyblue 9y ago
It does not, however - allow me to re-implement the methods based on the values passed into them. The greatest example of this is SQL: it takes the set of statements and transforms them into a set of steps a database needs to run in order to give you a result (and there are many ways of doing so). So essentially we end up with an optimisation problem that has to be solved (and many problems in computing are the optimisation problems where the question can be answered in many different ways). You could, however - argue that you could also implement an SQL-like language with the language of your choice; but then you had just re-implemented a DSL. And the last point against you is the fact that we are currently at the point where writing plugins for the IDEs is getting more easy, so quite frankly - the overhead of writing a new DSL is becoming less of an issue.