4 ms·

It seems to me that this is closely related to the idea of a domain specific language - "custom" and "embedded". There is a well-trodden path of "little langua

by jbert 15y ago

It seems to me that this is closely related to the idea of a domain specific language - "custom" and "embedded". There is a well-trodden path of "little languages" evolving over time to add features. (e.g. XML build files and templating languages accreting conditionals and control flow over time). To me these are "custom" DSLs and are generally a bad thing. [1] On the other hand, a DSL which leans on the language of it's implementation I consider a Good Thing. i.e. it is embedded in the implementation language, using it for control flow etc but also modifying it somehow (in a lisp, you'll get new special forms/structure/macros, in another language, you'll get a well-written API which allows easy expression of solutions to problems in the domain). [1] My reasons are mostly that they tend to be ill-suited for programming (no tooling such as code highlighting, debugger support, profiling etc - actions like this must be taken in the implementing language). In addition they tend to be poorly designed/idiosyncratic, because language design is hard. Of course, if the little language becomes sufficiently popular then this becomes a solved problem. I also note that my criticisms apply to interpreted languages implemented in C. So clearly good design and popularity can mitigate all or most of them.

prodigal_erik 15y ago
The drawback to leaning on the implementation language is that it encourages breaking the Rule of Least Power* . Documents using a minimal, declarative, non-Turing-complete grammar are much easier to analyze and repurpose. Once you add loops and conditionals, there's little any tool can say about what's going on other than just running it and watching what it did. * http://www.w3.org/2001/tag/doc/leastPower http://www.w3.org/2001/tag/doc/leastPower
- jbert 15y ago
  Fair point. But I'd say that such little languages exhibit feature creep over time. And once the two features you mention (looping + conditionals) are acquired, you've lost all the benefits you mention, since you're now turing complete. Regexes, makefiles, ant build files and even sendmail cfg files (http://okmij.org/ftp/Computation/sendmail-as-turing-machine.txt http://okmij.org/ftp/Computation/sendmail-as-turing-machine....) have grown in complexity from their first incarnations. I guess my position is: "Your language is very likely to grow over time - you might as well get the basics from a well designed language with a good toolset rather than design+implement it yourself". Note also the other way people attack this problem (lack of features in the little language) is to write "config file generators". i.e. programs in a general purpose lang which emit programs in the limited lang. That also tends to argue for the fact that such languages want to grow over time.
gte910h 15y ago
For every Sendmail, there are HUNDREDS of DSLs that never go past INI file level complexity. Most DSLs I've seen are for people who general purpose programming is beyond their daily capacity to use. It would be inappropriate to saddle decorated lisp on that person, or even LUA.
- jacques_chester 15y ago
  OT: "Lua". It's not an acronym.
  - gte910h 15y ago
    Ahh, it's Portugese for Moon.
- jbert 15y ago
  You're probably right, in that there is a useful role for pure "assign value X" languages. But also bear in mind that simple INI style files can be represented as data structure literals in the language. So you could replace your ini-style file: searchdir="/etc/foo" with (python syntax): searchdir="/etc/foo" and then load your cfg file with 'import' from python. This approach isn't perhaps suitable for all cases, but it also allows users to do "clever" things, e.g. replacing: server_host_1="foo" server_port_1=8000 server_host_1="foo" server_port_2=8010 server_host_1="foo" server_port_3=8020 server_host_1="foo" server_port_4=8030 with code. Basically, I'd urge anyone considering adding anything beyond simple assignement to use a real language, and even in the case of simple assignment, I think you can use a real language without scaring the users too much.
  - gte910h 15y ago
    You would be causing some nasty security issues with that approach I think.

by jbert 15y ago

prodigal_erik 15y ago

The drawback to leaning on the implementation language is that it encourages breaking the Rule of Least Power* . Documents using a minimal, declarative, non-Turing-complete grammar are much easier to analyze and repurpose. Once you add loops and conditionals, there's little any tool can say about what's going on other than just running it and watching what it did. * http://www.w3.org/2001/tag/doc/leastPower http://www.w3.org/2001/tag/doc/leastPower

jbert 15y ago
Fair point. But I'd say that such little languages exhibit feature creep over time. And once the two features you mention (looping + conditionals) are acquired, you've lost all the benefits you mention, since you're now turing complete. Regexes, makefiles, ant build files and even sendmail cfg files (http://okmij.org/ftp/Computation/sendmail-as-turing-machine.txt http://okmij.org/ftp/Computation/sendmail-as-turing-machine....) have grown in complexity from their first incarnations. I guess my position is: "Your language is very likely to grow over time - you might as well get the basics from a well designed language with a good toolset rather than design+implement it yourself". Note also the other way people attack this problem (lack of features in the little language) is to write "config file generators". i.e. programs in a general purpose lang which emit programs in the limited lang. That also tends to argue for the fact that such languages want to grow over time.

gte910h 15y ago

For every Sendmail, there are HUNDREDS of DSLs that never go past INI file level complexity. Most DSLs I've seen are for people who general purpose programming is beyond their daily capacity to use. It would be inappropriate to saddle decorated lisp on that person, or even LUA.

jacques_chester 15y ago
OT: "Lua". It's not an acronym.
- gte910h 15y ago
  Ahh, it's Portugese for Moon.
jbert 15y ago
You're probably right, in that there is a useful role for pure "assign value X" languages. But also bear in mind that simple INI style files can be represented as data structure literals in the language. So you could replace your ini-style file: searchdir="/etc/foo" with (python syntax): searchdir="/etc/foo" and then load your cfg file with 'import' from python. This approach isn't perhaps suitable for all cases, but it also allows users to do "clever" things, e.g. replacing: server_host_1="foo" server_port_1=8000 server_host_1="foo" server_port_2=8010 server_host_1="foo" server_port_3=8020 server_host_1="foo" server_port_4=8030 with code. Basically, I'd urge anyone considering adding anything beyond simple assignement to use a real language, and even in the case of simple assignment, I think you can use a real language without scaring the users too much.
- gte910h 15y ago
  You would be causing some nasty security issues with that approach I think.