2 ms·
I said "generalisation". You're thinking I mean DSLs in a static way - where they compile to a single static structure that is like a configuration file. I am t
by heavenlyblue 8y ago
I said "generalisation". You're thinking I mean DSLs in a static way - where they compile to a single static structure that is like a configuration file. I am trying to redefine the term here instead, because it seems more appropriate.
Essentially what I am asking here is: where do we set the line between "scripts" and "configuration files"? Because scripts are simply configuration files with a tree-like structure as they represent programs.
Scripts "configure the execution paths of your program".
A DSL thus is just a configuration file with a set of rules of applying those tree-like structures to each other.
- elcomet 8y agoScripts are definitely not configuration file. I would say the line is Turing-completeness. For me, DSL are half way between configuration files and scripts. If they are not Turing complete they are configuration languages. If they are, then they are programming language (with a specific use case). And I think that it is usually a bad idea to have configuration files in Turing complete languages (with exceptions, it can certainly be done well).
- heavenlyblue 8y ago>> Scripts are definitely not configuration file. >> I would say the line is Turing-completeness. >> For me, DSL are half way between configuration files and scripts _you_ would say. >> If they are not Turing complete they are configuration languages. If they are, then they are programming language (with a specific use case). Or, you could say that DSLs are what they are: "Domain Specific Languages". Which means that can either be a set of static definitions a-la configuration file, or on another side they can be scripts. All of these definitions fit really well the meaning of "Domain Specific Language".