4 ms·

The problem goes deeper. I can't remember who coined the term, but all "implerative" (imperative declarative) languages share the same issue. I don't care if it

The problem goes deeper. I can't remember who coined the term, but all "implerative" (imperative declarative) languages share the same issue. I don't care if it's JSON, XML, TOML, or YAML, we shouldn't be interpreting markup/data languages. GitHub actions are a good example of everything wrong with implerative languages. Use a real programming language, you can always read in JSON/YAML/whatever as configuration. Google zx is a good example of this done right, as is Pulumi. Kris Nóva said it best: "All config drifts towards Turing completion."

hosh 3y ago
I agree with all of this. If we take it one step further though and think about portability of configuration, I think that is one of the reasons we end up with operators.
Osiris 3y ago
For tools that allow configuration in either JSON or Javascript (like eslint), I prefer the JS version. The syntax is similar but has much more flexibility, like being able to use environment variables or add comments. Pulumi was also a good tool when I was doing kubernetes deployments.
sixdimensional 3y ago
"Implerative" - thank you for this, this is the term I've been searching for to describe the weird blending of the two things.. I immediately Googled it and saw that it has previous uses as well, I would love to know who originated the concept. I see so many times, confusion and arguing about what is imperative and declarative, to the point where I question the value of the terms any longer. FWIW, I have flirted with my own DSL implementations in a few cases. Certainly, language design is much more complex, but I also felt that once you understand enough of EBNF/parser generators (and some of the simpler alternatives), this is a very powerful option as well.
- sixdimensional 3y ago
  For the curious, this might be it: "I've cracked our marketing code, y'all! Pulumi: Implerative Appfrastructure" [1] @funcOfJoe, Joe Duffy: CEO of Pulumi [1] https://twitter.com/funcOfJoe/status/1319667607214067712 https://twitter.com/funcOfJoe/status/1319667607214067712
- sixdimensional 3y ago
  Also an interesting post referencing the term in a previous comment on HN: https://news.ycombinator.com/item?id=31182790 https://news.ycombinator.com/item?id=31182790
- zamalek 3y ago
  I'm also pretty against DSLs, although they do rarely have uses cases. For an example of why DSLs can be bad, look at Dockerfiles contrasted with Buildah. The former makes tons of assumptions, especially when to perform layer checkpoints. The latter is just a script in Bash or whatever your language of choice.
unshavedyak 3y ago
Oh man, i have a similar issue with NixLang. Though i know it's not "implarative". Many days i just want to write Nix in my preferred language. I wish Nix had made a simple JSON based IO for configuration, because then i could see what the output of something is - and generate the input state from some other language. Really frustrating. Nix works.. but i just don't see the value, personally. And this is after living on NixOS for ~3 years now, with 4 active Nix deploys in my house.. i just don't like the language.
- turboponyy 3y ago
  Completely opposite experience for me. I think Nixlang is exceptionally well designed and makes sense for the usecases it wants to cover, and it is exactly what I would expect from a DSL tackling the problems it tackles.
- zamalek 3y ago
  I'm currently building this (plus more) - the happy path of what you're talking about is almost complete. There are fundamental issues preventing what you're talking about being used as a complete replacement for NixLang: you'd need every possible language installed/available on the builder machine in order to build packages, and lazy evaluation would completely break (merely evaluating all of nixpkgs takes hours). So you do ultimately need a primary language. That being said, for devops-like stuff there is no reason to have that limitation.
  - unshavedyak 3y ago
    Would you be able to link the repo? I'm curious on your impl
    - zamalek 3y ago
      https://github.com/nickelpack/nck https://github.com/nickelpack/nck I wanted to use Nickel, but it turns out that it can't do everything you'd need it to do to completely replace NixLang. So right now I'm bikeshedding on what to use instead (and desperately trying not to invent something), in other words it's definitely being renamed. Either way there's a bash script in the `test` dir that shows the general concept.
shortrounddev2 3y ago
I've always wondered why we seem to have implemented a whole programming language in yaml or json for so many CI/CD systems rather than just writing quick python scripts to describe the logic of a particular build step, then MAYBE using a JSON or XML file to enumerate the build steps and their order, like: build: src/build.py test: src/test.py
- zamalek 3y ago
  Sure, that's orchestration, though. The problem with GHA is the sheer amount of expressive power that it has. If you need to do dynamic stuff then that should be in a "pre-workflow" step, written however/in whatever you please, that emits the actual workflow.
  - shortrounddev2 3y ago
    Why shouldn't the python script be the discrete workflow step? It could be mounted on some file system which has checked out the git at a particular commit with a particular tag, then runs whatever tasks are required to validate or deploy the project
    - zamalek 3y ago
      100%, though I think that the step visualization during the build does hold some value.

hosh 3y ago

I agree with all of this. If we take it one step further though and think about portability of configuration, I think that is one of the reasons we end up with operators.

Osiris 3y ago

For tools that allow configuration in either JSON or Javascript (like eslint), I prefer the JS version. The syntax is similar but has much more flexibility, like being able to use environment variables or add comments. Pulumi was also a good tool when I was doing kubernetes deployments.

sixdimensional 3y ago

"Implerative" - thank you for this, this is the term I've been searching for to describe the weird blending of the two things.. I immediately Googled it and saw that it has previous uses as well, I would love to know who originated the concept. I see so many times, confusion and arguing about what is imperative and declarative, to the point where I question the value of the terms any longer. FWIW, I have flirted with my own DSL implementations in a few cases. Certainly, language design is much more complex, but I also felt that once you understand enough of EBNF/parser generators (and some of the simpler alternatives), this is a very powerful option as well.

sixdimensional 3y ago
For the curious, this might be it: "I've cracked our marketing code, y'all! Pulumi: Implerative Appfrastructure" [1] @funcOfJoe, Joe Duffy: CEO of Pulumi [1] https://twitter.com/funcOfJoe/status/1319667607214067712 https://twitter.com/funcOfJoe/status/1319667607214067712
sixdimensional 3y ago
Also an interesting post referencing the term in a previous comment on HN: https://news.ycombinator.com/item?id=31182790 https://news.ycombinator.com/item?id=31182790
zamalek 3y ago
I'm also pretty against DSLs, although they do rarely have uses cases. For an example of why DSLs can be bad, look at Dockerfiles contrasted with Buildah. The former makes tons of assumptions, especially when to perform layer checkpoints. The latter is just a script in Bash or whatever your language of choice.

unshavedyak 3y ago

Oh man, i have a similar issue with NixLang. Though i know it's not "implarative". Many days i just want to write Nix in my preferred language. I wish Nix had made a simple JSON based IO for configuration, because then i could see what the output of something is - and generate the input state from some other language. Really frustrating. Nix works.. but i just don't see the value, personally. And this is after living on NixOS for ~3 years now, with 4 active Nix deploys in my house.. i just don't like the language.

turboponyy 3y ago
Completely opposite experience for me. I think Nixlang is exceptionally well designed and makes sense for the usecases it wants to cover, and it is exactly what I would expect from a DSL tackling the problems it tackles.
zamalek 3y ago
I'm currently building this (plus more) - the happy path of what you're talking about is almost complete. There are fundamental issues preventing what you're talking about being used as a complete replacement for NixLang: you'd need every possible language installed/available on the builder machine in order to build packages, and lazy evaluation would completely break (merely evaluating all of nixpkgs takes hours). So you do ultimately need a primary language. That being said, for devops-like stuff there is no reason to have that limitation.
- unshavedyak 3y ago
  Would you be able to link the repo? I'm curious on your impl
  - zamalek 3y ago
    https://github.com/nickelpack/nck https://github.com/nickelpack/nck I wanted to use Nickel, but it turns out that it can't do everything you'd need it to do to completely replace NixLang. So right now I'm bikeshedding on what to use instead (and desperately trying not to invent something), in other words it's definitely being renamed. Either way there's a bash script in the `test` dir that shows the general concept.

shortrounddev2 3y ago

I've always wondered why we seem to have implemented a whole programming language in yaml or json for so many CI/CD systems rather than just writing quick python scripts to describe the logic of a particular build step, then MAYBE using a JSON or XML file to enumerate the build steps and their order, like: build: src/build.py test: src/test.py

zamalek 3y ago
Sure, that's orchestration, though. The problem with GHA is the sheer amount of expressive power that it has. If you need to do dynamic stuff then that should be in a "pre-workflow" step, written however/in whatever you please, that emits the actual workflow.
- shortrounddev2 3y ago
  Why shouldn't the python script be the discrete workflow step? It could be mounted on some file system which has checked out the git at a particular commit with a particular tag, then runs whatever tasks are required to validate or deploy the project
  - zamalek 3y ago
    100%, though I think that the step visualization during the build does hold some value.