3 ms·

Yeah at one job I worked, a smart but then-inexperienced guy had developed a language, implemented a transpiler, written a bunch of tooling in the language, and

Yeah at one job I worked, a smart but then-inexperienced guy had developed a language, implemented a transpiler, written a bunch of tooling in the language, and left the company. We'll call him "Steve". By the time I got there it had been largely replaced, but one still heard rumors about the dreaded "Stevecode".

deleted 6y ago
[deleted]
dkersten 6y ago
I wrote a little mini language[1] for a project last year (I only inflicted it on myself, not any poor user). It served its purpose well: allowing me to quickly implement people's requests in a way that was sandboxed/isolated from other people's accounts, was impossible to take the system down no matter how bad the bugs, and I could implement these requests without redeploying the underlying system. In that respect, it was a huge success (and that's what it was for). But in every other way, I think it was a failure: I came to hate writing code in it, despite having designed it. It had missing language features that I never got around to implementing, strange bugs that I didn't have time to fix (so just avoided doing those things), nobody else but me could use it (the project was just me developing, but the users couldn't use it either despite having access to it. It replaced a simple but very limited command language, but in doing so added too much real programming). So while it succeeded in what it set out to do, it wasn't a sustainable or future proof solution. I did learn what users actually wanted though and got to test/prototype it before adding it to the underlying system. I'm also working on a declarative replacement now (basically a TOML file where values can be expressions -- a template system), that supports everything the users actually want, but is vastly simpler and has much less custom logic. It was a great learning experience though and I'm glad I did it, both in terms of learning how to write grammars (I used Clojure's Instaparse) and interpreters, and in learning about the users needs and wants. But I shudder to think about if anybody else would have had to use it... [1] Some interesting (IMHO) technical details: it was a synchronous language (of the transformational system variety), meaning that while it was executing, time was essentially frozen: it would gather all of its inputs, then evaluate the code as a pure transformation of its inputs (made it very easy to interpret!) and then write its output. The inputs are essentially immutable while the evaluation is happening. This was run in a database transaction for consistency. Each individual script was basically stop-the-world non-concurrent, but the scripts were independent and many could execute at once. I'm a very big fan of event driven synchronous languages.
- 4WIW 6y ago
  Thanks for sharing. There are often good reasons for creating DSLs, internal or external. However I argue that I haven't seen many cases where configuration DSL were well justified. By configuration here I mean something that describes differences between different deployed instances of the same code. If you take all deployed instances of the existing system and see what is minimal amount of configuration to describe these, you would usually find that very little information, just a few lines would be enough. The rest of configuration file complexity comes from the designer's attempts to predict the future extensions. My point is, these should be resisted for the sake of future generations of maintainers.
  - dkersten 6y ago
    What do you think of the HashiCorp configuration language (HCL)? Overall, I completely agree with you, but I do find that HCL seems to be a pretty good fit for what its used for (at least for Terraform, which I have more experience with than their other tools). My little story was really just me dumping my thoughts after reading about Stevecode, as someone who made a little language (not a configuration language though) and isn't an argument for doing so at all. I'm definitely in favour of sticking with an existing format for configuration (personally, I like to use TOML or EDN for my own projects' configuration needs, or JSON if its not normally meant to be edited by humans) and even for scripting, normally I'd stick with Lua or Javascript. My language came into existence because neither of those was sandboxed in the way I wanted (it was also deterministic and guaranteed to halt as there were no unbounded loops).
    - 4WIW 6y ago
      Hah...Terraform is called "Infrastructure as code", so it's HCL language is "code", not configuration, at least by my definition. The whole point of configuration is that it's not code. I use a simple litmus test: can your system work at least to some extent with empty configuration file? If not, you went too far and need to simplify.

deleted 6y ago

[deleted]

dkersten 6y ago

I wrote a little mini language[1] for a project last year (I only inflicted it on myself, not any poor user). It served its purpose well: allowing me to quickly implement people's requests in a way that was sandboxed/isolated from other people's accounts, was impossible to take the system down no matter how bad the bugs, and I could implement these requests without redeploying the underlying system. In that respect, it was a huge success (and that's what it was for). But in every other way, I think it was a failure: I came to hate writing code in it, despite having designed it. It had missing language features that I never got around to implementing, strange bugs that I didn't have time to fix (so just avoided doing those things), nobody else but me could use it (the project was just me developing, but the users couldn't use it either despite having access to it. It replaced a simple but very limited command language, but in doing so added too much real programming). So while it succeeded in what it set out to do, it wasn't a sustainable or future proof solution. I did learn what users actually wanted though and got to test/prototype it before adding it to the underlying system. I'm also working on a declarative replacement now (basically a TOML file where values can be expressions -- a template system), that supports everything the users actually want, but is vastly simpler and has much less custom logic. It was a great learning experience though and I'm glad I did it, both in terms of learning how to write grammars (I used Clojure's Instaparse) and interpreters, and in learning about the users needs and wants. But I shudder to think about if anybody else would have had to use it... [1] Some interesting (IMHO) technical details: it was a synchronous language (of the transformational system variety), meaning that while it was executing, time was essentially frozen: it would gather all of its inputs, then evaluate the code as a pure transformation of its inputs (made it very easy to interpret!) and then write its output. The inputs are essentially immutable while the evaluation is happening. This was run in a database transaction for consistency. Each individual script was basically stop-the-world non-concurrent, but the scripts were independent and many could execute at once. I'm a very big fan of event driven synchronous languages.

4WIW 6y ago
Thanks for sharing. There are often good reasons for creating DSLs, internal or external. However I argue that I haven't seen many cases where configuration DSL were well justified. By configuration here I mean something that describes differences between different deployed instances of the same code. If you take all deployed instances of the existing system and see what is minimal amount of configuration to describe these, you would usually find that very little information, just a few lines would be enough. The rest of configuration file complexity comes from the designer's attempts to predict the future extensions. My point is, these should be resisted for the sake of future generations of maintainers.
- dkersten 6y ago
  What do you think of the HashiCorp configuration language (HCL)? Overall, I completely agree with you, but I do find that HCL seems to be a pretty good fit for what its used for (at least for Terraform, which I have more experience with than their other tools). My little story was really just me dumping my thoughts after reading about Stevecode, as someone who made a little language (not a configuration language though) and isn't an argument for doing so at all. I'm definitely in favour of sticking with an existing format for configuration (personally, I like to use TOML or EDN for my own projects' configuration needs, or JSON if its not normally meant to be edited by humans) and even for scripting, normally I'd stick with Lua or Javascript. My language came into existence because neither of those was sandboxed in the way I wanted (it was also deterministic and guaranteed to halt as there were no unbounded loops).
  - 4WIW 6y ago
    Hah...Terraform is called "Infrastructure as code", so it's HCL language is "code", not configuration, at least by my definition. The whole point of configuration is that it's not code. I use a simple litmus test: can your system work at least to some extent with empty configuration file? If not, you went too far and need to simplify.