4 ms·
A proper [e]DSL should almost always be preferred to a library. For the very obvious reasons.
by sklogic 11y ago
A proper [e]DSL should almost always be preferred to a library. For the very obvious reasons.
- tveita 11y agoI don't think that's obvious, and my experience is the opposite. Domain specific languages make for pretty example code, but tend to lose some of the flexibility of the underlying general purpose language, which can cause you trouble later on when you want to feed the output of one command into another, do a slight tweak to the input format, or just about anything the author of the DSL didn't anticipate. Libraries tend to be more composable, and can be used with other libraries. Mashing together two DSLs can be close to impossible.
- sklogic 11y agoWeird position. Libraries are: - Limited to the host language syntax - Littered with unrelated abstractions from the host language - Not flexible and not composable enough to be usable - SLO-O-OW - you cannot do domain-specific optimisations for libraries and so called "fluent" DSLs - Very poor tooling (or no tooling at all) With eDSLs you have: - Pure essence of the problem domain, no unrelated abstractions - Nice tooling (syntax highlighting, semantic navigation, context-sensitive suggestions, etc.) - Flexibility - you can drop your entire DSL implementation and swap for another one without changing a single line of the user code - Composability - it's very easy to mix DSLs together, to build new DSLs out of bits and pieces of the existing ones. - Performance - you can perform as many domain-specific optimisations as you like - Quality - add any kind of static type system to your DSL to check for the problem domain-specific constraints. > Mashing together two DSLs can be close to impossible. What?!? Unbelievable.
- rprospero 11y ago> > Mashing together two DSLs can be close to impossible. > What?!? Unbelievable. Let me put the unbelievable into concrete terms for you. On a previous project, I had a program that needed to repeatedly do the following 1) Download and XML config file 2) Parse said XML file for a set of voltages 3) Send the voltages over a set of power supplies 4) Retrieve a new array of voltages from our ADCs 5) Plot the voltages 6) Display the plots on a webpage At an early point in the project, everything was using the best DSL for the job. The XML was parsed via XSLT. LabView was used to control the power supplies and ADCs. OriginPro provided the plots. The web pages were written in php. However, the amount of effort that went into channeling the data between AWK, LabView, OriginPro, and php was found to be far greater than what it took to write a new application that did all of it in Python. No single stage of the process was as easy as it had been in the DSL, but the impedance mismatch between the languages was nightmarish.
- dllthomas 11y agosklogic is talking about DSLs embedded in a host language. You are comparing it to external DSLs, some of which were built not to play particularly well with others. You can, of course, still have impedance mismatch between eDSLs, but you're just not talking about the same things.
- rprospero 11y agoSorry about that. Looking back, he even said eDSL in his post. Yeah, embedded DSLs are awesome.
- sklogic 11y agoOf course. Not having a single common fabric for all the DSLs can be a nightmare. For this reason, eDSLs built on top of a common, sufficiently powerful metalanguage are much better than any standalone DSL. The said Maru seems to be sufficiently powerful.
- nickpsecurity 11y agoComposability, optimization, type checking per DSL, and type-checking globally in host language can combine to offer real power to someone wanting productivity and robustness in combination. Not enough work in this area considering potential benefits.