3 ms·

> Build systems inevitably evolve into something turing complete. CI systems are also generally distributed. You want to build and test on all target environme

> Build systems inevitably evolve into something turing complete. CI systems are also generally distributed. You want to build and test on all target environments before landing a change or cutting a release! What Turing complete language cleanly models some bits of code running on one environment and then transitions to other code running on an entirely different environment? Folks tend to go declarative to force environment-portable configuration. Arguably that's impossible and/or inflexible, but the pain that drives them there is real. If there is a framework or library in a popular scripting language that does this well, I haven't seen it yet. A lot of the hate for Jenkinsfile (allegedly a groovy-based framework!) is fallout from not abstracting the heterogeneous environment problem.

pydry 6y ago
>What Turing complete language cleanly models some bits of code running on one environment and then transitions to other code running on an entirely different environment? Any language that runs in both environments with an environment abstraction that spans both? >Folks tend to go declarative to force environment-portable configuration. Declarative is always better if you can get away with it. However, it inevitably hamstrings what you can do. In most declarative build systems some dirty turing complete hack will inevitably need to be shoehorned in to get the system to do what it's supposed to. A lot of build systems have tried to pretend that this won't happen but it always does eventually once a project grows complex enough.
- humanrebar 6y ago
  > Any language that runs in both environments with an environment abstraction that spans both? Do you have examples? This is harder to do than it would seem. You would need an on demand environment setup (a virtualenv and a lockfile?) or a homogeneous environment and some sort of RPC mechanism (transmit a jar and execute). I expect either to be possible, though I expect the required verbosity and rigor to impede significant adoption. Basically, I think folks are unrealistic about the ability to be pithy, readable, and robust at the same time.
  - pydry 6y ago
    >Do you have examples? This is harder to do than it would seem. Examples of cross platform code? There are millions. >You would need an on demand environment setup (a virtualenv and a lockfile?) or a homogeneous environment and some sort of RPC mechanism (transmit a jar and execute). I expect either to be possible, though I expect the required verbosity and rigor to impede significant adoption. Why need it be verbose? A high level rewuorements, a lock file and one or two code files ought to be sufficient for most purposes.
    - humanrebar 6y ago
      We're not talking about a program that could run on any given platform (cross platform). We're talking about one program that is distributed across several machines in one workflow. That's a form of distributed (usually) heterogeneous computation. And typically with a somewhat dynamic execution plan. Mix in dynamic discovery of (or configuration of) executing machines and you have a lot of complexity to manage. This is why I wanted to see some specific examples. I haven't seen much success in this space that is general purpose. The closest I have seen is "each step in the workflow is a black box implemented by a container", which is often pretty good, though it isn't a procedural script written in a well known language. And it does make assumptions about environment (i.e. usually Linux).

pydry 6y ago

>What Turing complete language cleanly models some bits of code running on one environment and then transitions to other code running on an entirely different environment? Any language that runs in both environments with an environment abstraction that spans both? >Folks tend to go declarative to force environment-portable configuration. Declarative is always better if you can get away with it. However, it inevitably hamstrings what you can do. In most declarative build systems some dirty turing complete hack will inevitably need to be shoehorned in to get the system to do what it's supposed to. A lot of build systems have tried to pretend that this won't happen but it always does eventually once a project grows complex enough.

humanrebar 6y ago
> Any language that runs in both environments with an environment abstraction that spans both? Do you have examples? This is harder to do than it would seem. You would need an on demand environment setup (a virtualenv and a lockfile?) or a homogeneous environment and some sort of RPC mechanism (transmit a jar and execute). I expect either to be possible, though I expect the required verbosity and rigor to impede significant adoption. Basically, I think folks are unrealistic about the ability to be pithy, readable, and robust at the same time.
- pydry 6y ago
  >Do you have examples? This is harder to do than it would seem. Examples of cross platform code? There are millions. >You would need an on demand environment setup (a virtualenv and a lockfile?) or a homogeneous environment and some sort of RPC mechanism (transmit a jar and execute). I expect either to be possible, though I expect the required verbosity and rigor to impede significant adoption. Why need it be verbose? A high level rewuorements, a lock file and one or two code files ought to be sufficient for most purposes.
  - humanrebar 6y ago
    We're not talking about a program that could run on any given platform (cross platform). We're talking about one program that is distributed across several machines in one workflow. That's a form of distributed (usually) heterogeneous computation. And typically with a somewhat dynamic execution plan. Mix in dynamic discovery of (or configuration of) executing machines and you have a lot of complexity to manage. This is why I wanted to see some specific examples. I haven't seen much success in this space that is general purpose. The closest I have seen is "each step in the workflow is a black box implemented by a container", which is often pretty good, though it isn't a procedural script written in a well known language. And it does make assumptions about environment (i.e. usually Linux).