3 ms·

You sound like a marketer trying to sell a fridge on a phone call. > Why complicate your real program with that? Offload it to dhall and you get a consistent

by antpls 8y ago

You sound like a marketer trying to sell a fridge on a phone call. > Why complicate your real program with that? Offload it to dhall and you get a consistent configuration for free! Why complicate my projects pipeline and force my team to learn yet another tool that may just be abandonned in 3 months? > Dhall could do much of the same work of producing a simple spec, but without the fear of infinite loops or nonsensical Bash parameters hitting a function. Last time I wrote an infinite loop in Python was... I can't remember. Maybe 5 years ago? Nonsensical is subjective. Maybe Dhall only makes sense to you. > Dhall is such a simple language There is no objective criteria to define a "simple" language. Perl was simple to some people. > If what you really want is a declarative set of instructions to your real program, Dhall is probably one of the most awesome tools in the open source world for making it. Or you could write a nice Python library, with clean API, and eventually a linter that makes sure the Python configuration file is a restricted subset of Python.

KirinDave 8y ago
> You sound like a marketer trying to sell a fridge on a phone call. I've got no stake in Dhall and I'm not a contributor. Check my submission history to see the sorts of things I try to do at HN if you're curious what my agenda here is. > Why complicate my projects pipeline and force my team to learn yet another tool that may just be abandonned in 3 months? Dhall's substantially older than this and open source, so its not really an attrition risk in 2018. But I'd argue your pipeline is already complicated. My CircleCI2 flow got enourmously simpler when I was no longer struggling to represent complex concepts in YAML and could just produce an object graph in Dhall and then render it to the right YAML. I've also switched to using it to generate json for mesos API calls to make sure I get the fields right. > Or you could write a nice Python library, with clean API, and eventually a linter that makes sure the Python configuration file is a restricted subset of Python. I grant, this is possible. But why does having it "in Python" matter? How does that help people writing Golang or C# or Ocaml or Scala or Ruby? Dhall's decision to template out more standard files is a smart one, it means it can serve as a stand-in and let programs that do the heavy lifting of a product or process (e.g., a Python ML binding or airflow process) use their normal tooling and do what they love. If you're mad it is written in Haskell, I dunno what to tell you other than that it's like "jq". The host language doesn't matter because you invoke it for its outputs.
- antpls 8y ago
  > Check my submission history to see the sorts of things I try to do at HN if you're curious what my agenda here is. I don't care where you come from, I'm judging the arguments in this thread. > My CircleCI2 flow got enourmously simpler "Enormously" is relative. Do you have any numbers? > But why does having it "in Python" matter? Because of the Bus factor. Many more people already know Python. > Dhall's decision to template out more standard files is a smart one The smartest move is the one that makes the most economical sense. Do you have number to prove it's a smart decision?
  - haskellandchill 8y ago
    Actually, believe it or not, economics is not the only measure we have to respect. There is joy in simplicity and understandability that does not need to be mapped to costs on a number line.
  - KirinDave 8y ago
    There is no single economic perspective I can offer that can decide what tool is right for your org. Personally, I think that's an unfair question, since any answer I have would be uninformed to your specific circumstances. It'd always be wrong. I'm sorry I can't work out what you like from this conversation. I've used this tool, I like this tool, and I'm comfortable with it. As such, I thought I'd share it since there's also a TOML article on the front page today.
chriswarbo 8y ago
> There is no objective criteria to define a "simple" language. Perl was simple to some people. That's nonsense. Here are several: - The Chomsky hierarchy: regular expressions (finite state machines) are objectively simpler than context free languages (pushdown automata), which are objectively simpler than Turing-complete languages (Turing machines). - "Pure" languages (which only calculate an output, deterministically, using only the given input) are simpler than "impure" languages (which can also alter the world via irreversible effects, and those affects may alter subsequent behaviour, even across iterations) - Untyped languages are simpler than typed languages, since all values are interchangable (this is sometimes called "unityped", since there's one big type) - Globally scoped languages are simpler than locally scoped languages (whether lexical, dynamic, whatever) - First-order languages are simpler than higher-order languages (just ask any compiler designer!) - Statically-dispatched languages are simpler than dynamically-dispatched languages - Languages with local control flow are simpler than those with non-local control flow (e.g. exceptions, GOTO, etc.) Those are just off the top of my head. Of course, simple languages aren't necessarily better languages, since it depends on the task. The same goes for anything, e.g. building with Lego is simpler than building with welded metal, but Lego is not appropriate for building a car. The above list isn't making value judgements about those features, it's just stating which is objectively simpler (there's a reason we don't program everthing in SK logic!). As for the languages being discussed here: - Python is Turing complete, impure, untyped, locally-scoped, dynamically-dispatched with non-local control flow - Perl is Turing complete, impure, untyped, locally-scoped, dynamically-dispatched with non-local control flow - Dhall is not Turing complete, pure, typed, locally-scoped, statically-dispatched with local control flow In particular, I don't see the point of advocating Python while using Perl as a negative example. As imperative, interpreted, dynamic scripting languages they're pretty much identical (see "LAMP stack" for example); arguing between such similar options is mostly subjective, and probably devolves into a tyranny of small differences. On the other hand Dhall is a very different language. It is objectively simpler across many different criteria (although more complex by a few, like its types). In particular, due to its simplicity we can have much more confidence that a Dhall program is correct than in a language like Perl or Python. For example: - If evaluating a Dhall program gives the right answer, we know that evaluating it again will give the same right answer, since Dhall programs cannot change their behaviour unless we change their input. - We know, without even looking at a Dhall program, that it will not perform unintended or malicious actions like deleting files, sending emails, keylogging, etc. This is because the Dhall language is incapable of doing such things (it is pure). - If we're able to run a Dhall program at all, the type system will have ruled out certain classes of mistake (note this is an objective fact; the holy war around typing is about whether that's worth doing or not) To me, another advantage of using a limited, single-purpose language like Dhall for configuration rather than e.g. Python is that it can withstand pressure to add hacks, preprocessing and other complications. I've worked on applications which defined their configuration in the same language as the program, and it wasn't long before that "configuration" was branching on environment variables, hostnames, etc. to distinguish between systems (e.g. dev, test, staging, production). Once those braches were in place, it wasn't long before system-specific functionality started creeping into them (since "before everything else" can be an easy place to add patches). Once the available functionality started depending on code from the "config" file, it wasn't long before an override mechanism was needed to trick the "config" into which system it should pretend to be on. At that point we need config for the config, and the cycle continues. Sure you could blame bad developers, but that's only useful with hindsight. Pretty much every segfault, security issue, crash, bug, etc. can all be backsplained as avoidable mistakes made by bad programmers. Yet we still, as a community, decided to create automatic memory management, sandboxes, restart loops, bug trackers, etc. because we accept that we will make mistakes, and it's better to mitigate their damage, or avoid giving ourselves that power/responsibility in the first place, than it is to point fingers and assign blame after a catastrophe. Truly bad programmers are those who refuse to automate tasks: piling up mental burdens until eventually something slips, rather than letting the machine deal with it. Infinite loops are a simple example: personal anecdotes do not solve the halting problem; making a language which always halts does (for that language). Enforcing policies using a linter can be a good idea, as it makes the machine responsible. Yet linting is usually a last resort, since it's necessarily limited (especially in a language as dynamic as Python, where behaviour can be redefined in non-obvious ways). Also, a machine-enforced language subset is essentially a different language. It also seems disigenuous to pose a solution involving hypothetical linters that don't yet exist, after raising concerns about abandonment for an established, feature-complete project.

by antpls 8y ago

KirinDave 8y ago

> You sound like a marketer trying to sell a fridge on a phone call. I've got no stake in Dhall and I'm not a contributor. Check my submission history to see the sorts of things I try to do at HN if you're curious what my agenda here is. > Why complicate my projects pipeline and force my team to learn yet another tool that may just be abandonned in 3 months? Dhall's substantially older than this and open source, so its not really an attrition risk in 2018. But I'd argue your pipeline is already complicated. My CircleCI2 flow got enourmously simpler when I was no longer struggling to represent complex concepts in YAML and could just produce an object graph in Dhall and then render it to the right YAML. I've also switched to using it to generate json for mesos API calls to make sure I get the fields right. > Or you could write a nice Python library, with clean API, and eventually a linter that makes sure the Python configuration file is a restricted subset of Python. I grant, this is possible. But why does having it "in Python" matter? How does that help people writing Golang or C# or Ocaml or Scala or Ruby? Dhall's decision to template out more standard files is a smart one, it means it can serve as a stand-in and let programs that do the heavy lifting of a product or process (e.g., a Python ML binding or airflow process) use their normal tooling and do what they love. If you're mad it is written in Haskell, I dunno what to tell you other than that it's like "jq". The host language doesn't matter because you invoke it for its outputs.

antpls 8y ago
> Check my submission history to see the sorts of things I try to do at HN if you're curious what my agenda here is. I don't care where you come from, I'm judging the arguments in this thread. > My CircleCI2 flow got enourmously simpler "Enormously" is relative. Do you have any numbers? > But why does having it "in Python" matter? Because of the Bus factor. Many more people already know Python. > Dhall's decision to template out more standard files is a smart one The smartest move is the one that makes the most economical sense. Do you have number to prove it's a smart decision?
- haskellandchill 8y ago
  Actually, believe it or not, economics is not the only measure we have to respect. There is joy in simplicity and understandability that does not need to be mapped to costs on a number line.
- KirinDave 8y ago
  There is no single economic perspective I can offer that can decide what tool is right for your org. Personally, I think that's an unfair question, since any answer I have would be uninformed to your specific circumstances. It'd always be wrong. I'm sorry I can't work out what you like from this conversation. I've used this tool, I like this tool, and I'm comfortable with it. As such, I thought I'd share it since there's also a TOML article on the front page today.

chriswarbo 8y ago

> There is no objective criteria to define a "simple" language. Perl was simple to some people. That's nonsense. Here are several: - The Chomsky hierarchy: regular expressions (finite state machines) are objectively simpler than context free languages (pushdown automata), which are objectively simpler than Turing-complete languages (Turing machines). - "Pure" languages (which only calculate an output, deterministically, using only the given input) are simpler than "impure" languages (which can also alter the world via irreversible effects, and those affects may alter subsequent behaviour, even across iterations) - Untyped languages are simpler than typed languages, since all values are interchangable (this is sometimes called "unityped", since there's one big type) - Globally scoped languages are simpler than locally scoped languages (whether lexical, dynamic, whatever) - First-order languages are simpler than higher-order languages (just ask any compiler designer!) - Statically-dispatched languages are simpler than dynamically-dispatched languages - Languages with local control flow are simpler than those with non-local control flow (e.g. exceptions, GOTO, etc.) Those are just off the top of my head. Of course, simple languages aren't necessarily better languages, since it depends on the task. The same goes for anything, e.g. building with Lego is simpler than building with welded metal, but Lego is not appropriate for building a car. The above list isn't making value judgements about those features, it's just stating which is objectively simpler (there's a reason we don't program everthing in SK logic!). As for the languages being discussed here: - Python is Turing complete, impure, untyped, locally-scoped, dynamically-dispatched with non-local control flow - Perl is Turing complete, impure, untyped, locally-scoped, dynamically-dispatched with non-local control flow - Dhall is not Turing complete, pure, typed, locally-scoped, statically-dispatched with local control flow In particular, I don't see the point of advocating Python while using Perl as a negative example. As imperative, interpreted, dynamic scripting languages they're pretty much identical (see "LAMP stack" for example); arguing between such similar options is mostly subjective, and probably devolves into a tyranny of small differences. On the other hand Dhall is a very different language. It is objectively simpler across many different criteria (although more complex by a few, like its types). In particular, due to its simplicity we can have much more confidence that a Dhall program is correct than in a language like Perl or Python. For example: - If evaluating a Dhall program gives the right answer, we know that evaluating it again will give the same right answer, since Dhall programs cannot change their behaviour unless we change their input. - We know, without even looking at a Dhall program, that it will not perform unintended or malicious actions like deleting files, sending emails, keylogging, etc. This is because the Dhall language is incapable of doing such things (it is pure). - If we're able to run a Dhall program at all, the type system will have ruled out certain classes of mistake (note this is an objective fact; the holy war around typing is about whether that's worth doing or not) To me, another advantage of using a limited, single-purpose language like Dhall for configuration rather than e.g. Python is that it can withstand pressure to add hacks, preprocessing and other complications. I've worked on applications which defined their configuration in the same language as the program, and it wasn't long before that "configuration" was branching on environment variables, hostnames, etc. to distinguish between systems (e.g. dev, test, staging, production). Once those braches were in place, it wasn't long before system-specific functionality started creeping into them (since "before everything else" can be an easy place to add patches). Once the available functionality started depending on code from the "config" file, it wasn't long before an override mechanism was needed to trick the "config" into which system it should pretend to be on. At that point we need config for the config, and the cycle continues. Sure you could blame bad developers, but that's only useful with hindsight. Pretty much every segfault, security issue, crash, bug, etc. can all be backsplained as avoidable mistakes made by bad programmers. Yet we still, as a community, decided to create automatic memory management, sandboxes, restart loops, bug trackers, etc. because we accept that we will make mistakes, and it's better to mitigate their damage, or avoid giving ourselves that power/responsibility in the first place, than it is to point fingers and assign blame after a catastrophe. Truly bad programmers are those who refuse to automate tasks: piling up mental burdens until eventually something slips, rather than letting the machine deal with it. Infinite loops are a simple example: personal anecdotes do not solve the halting problem; making a language which always halts does (for that language). Enforcing policies using a linter can be a good idea, as it makes the machine responsible. Yet linting is usually a last resort, since it's necessarily limited (especially in a language as dynamic as Python, where behaviour can be redefined in non-obvious ways). Also, a machine-enforced language subset is essentially a different language. It also seems disigenuous to pose a solution involving hypothetical linters that don't yet exist, after raising concerns about abandonment for an established, feature-complete project.