4 ms·

All these kinds of HN comments share the same flaw: they unnecessarily detract from the work the OP has done by attacking use cases that the project never claim

All these kinds of HN comments share the same flaw: they unnecessarily detract from the work the OP has done by attacking use cases that the project never claimed to solve. DSL's, for all their problems, do simplify complex programming logic, and people use them every day to do great things. DSL's like Ansible and Chef save people an order of magnitude of time for server provisioning hence why they are wildly popular. It seems reasonable to me that someone would build a DSL with the same goals for web browser automation. The screen recording example gif they have looks so intuitive even a non-programmer could do it. I don't look at this project and expect that it solved every problem with web scraping and reading the README it doesn't look like they are claiming it does either.

yachtman 7y ago
All these kinds of HN comments share the same flaw, in failing to recognize that the primary obsession of hacker news is in discussing the flaws of things posted on hacker news.
- ajoy 7y ago
  I would argue that thats the benefit. I want people more knowledgable than me to comment and point out the flaws in products/reports/theories. Thats what I love about HN. How critical are those flaws? It's up to you. If you take the approach of "there is no right or wrong, only opinions" when you read comments, it's much better off.
  - plufz 7y ago
    I would argue that trying to find flaws is flawed (atleast in this context). Much better to use a neutral approach where you are equally open to strength and flaws.
threatofrain 7y ago
Using Ansible is what made me lose faith in DSL's in all the ways mentioned (eventually wanted loops, conditions, variables and namespaces...). Ansible is an API over a domain and if it were originally just represented through a Python language library I don't see why it would be less accessible or productive. Even something as simple as YAML can be screwed up and turned complicated.
- alwillis 7y ago
  Even though I know how to program, I really like Ansible and probably wouldn’t have gotten into it if it had the same functionality but used Python instead of YAML.
- farisjarrah 7y ago
  Building infrastructure is complicated. Have you found an easier way then Ansible to accomplish building infrastructure? Ansible does make yaml more complicated, however, you don't need to use much of that complexity for simple projects. Compared to Terraform, Chef, Google Deployment Manager, and Windows Desired State Configuration, Ansible is by far the simplest to get up and running on to do real work with.
  - erikpukinskis 7y ago
    AWS CDK would be an example of using a programming language rather than a DSL to build infra.
    - ofrzeta 7y ago
      There's also Pulumi that covers a wider range of infrastructure than AWS only.
- Middleclass 7y ago
  Have you tried SaltStack? It uses YAML too, but always felt much more cleanly composed, and smoothly integrates with scripting languages. I've never truly broken into orchestration and am still salty about that so please, take my post with a grain of salt. (Full disclosure: I have literally no professional affiliations whatsoever.)
- cryptonector 7y ago
  > Even something as simple as YAML can be screwed up and turned complicated. Your problem is that you think YAML is simple.
erikpukinskis 7y ago
Some of us legitimately believe DSLs are rarely the right choice. We don’t say this to shit on people’s work, we say it to kick off a conversation about API design. I’ve written DSLs in the past. I was a Rubyist! I have come to some perspective on those choices in the intervening years. I’m a big fan of functions that take arguments, and I am skeptical of hidden shared state.
- debaserab2 7y ago
  You can be skeptical of DSL's but still recognize that they provide a time/complexity trade-off. I agree that it's probably not the right decision to write your own DSL for something but to dogmatically crusade against all DSL's feels silly to me when there are so many popular projects using them. Ansible is popular because it is accessible to devop type roles (previously known as sysadmin or IT services) that may know some programming but would fail to produce results nearly as fast if they were simply left with python libraries. It would not be as popular as it is today if it were simply a python library. Criticizing this project for using a DSL as it's interface over some programmer purity test BS is completely missing the forest for the trees.
  - erikpukinskis 7y ago
    > they provide a time/complexity trade-off I think that’s too specific of a claim for such a broad category as DSLs. I think in specific cases there is a time-complexity tradeoff you can exploit, those are the (IMO extremely rare) cases where a DSL is worth considering. But in a lot of cases it’s just added complexity. Functions are pretty powerful. And they are also easier to reason about. Often the DSL adds “time” because you’re like “why the heck isn’t this working” and it’s because of some weird state you can’t inspect that’s deep inside your parse tree. “Guess I better start reading the source code of my DSL runtime. Oh look, someone hacked a corner care into the parser.” My rule of thumb would be something like: 1) if you have time to make your DSL superbly executed, and 2) you are very certain it can make an entire class of problems go away, and 3) you don’t expect weird corner cases to ever show up in a future project that break the model ...then it’s worth considering. As a professional coder though, I don’t see a lot of situations like that. In particular the “build this module superbly” is generally not an option on the table. Nor is “you can model the domain of future needs thoroughly” But I work at startups, I bet at a BigCo if you are a very senior person DSLs are on the table more often.
nonbirithm 7y ago
I tried using Ansible once and could never escape the fact that anything complex like installing files or raising docker containers requires the use of external modules with actual code and templated YAML. Every time something "templated" shows up in a supposedly "declarative" language it feels like the designers had to add on features from an actual programming language to do what they wanted, because the DSL was too declarative and static to accomplish anything useful. For example, look at this Azure deployment template: https://github.com/Azure/azure-quickstart-templates/blob/65d6fe33c1c1789ef13f4c3f94d0634de0b156d3/101-vm-simple-windows/azuredeploy.json#L54 https://github.com/Azure/azure-quickstart-templates/blob/65d... Notice all the inline function calls. They basically modified JSON with their own domain-specific "functions" like "concat" and have an entire section dedicated to "variables" because in standard JSON this is not possible to express. Already this sounds like a scripting language, except terribly watered down and specific only to Azure services. As a personal anecdote, I once made the dumb mistake of choosing a static config file instead of a dynamic one when I was developing a mod system for a game. The problem became that there were things like function callbacks that I wanted to add in, so that meant I ended up writing inline "pointers" to a place where a Lua callback existed as an identifier, instead of inlining it as Lua code, then it went through an unnecessary transpilation step to Lua data structures. My mistake was assuming that the DSL was expressive enough for my needs, which included loops, inline function callbacks and code generation, when clearly it was not. Sometimes the effort people expend to make declarative configs work out are significant. The OpenAge project (an engine rewrite of Age of Empires II) uses a declarative language called nyan[1] which describes the changes of things like unit health or cost. It's entirely custom-made for the engine. The moment that I realized that declarative configs were not for me was when I realized that this declarative language, which the author wrote an entire PhD thesis over and was specifically designed for the purpose of game modding, would still not be expressive for the things I was envisioning. In the end Lua, a general-purpose language that had existed for decades, was the better choice. There was no need to muck around with writing new languages or munging the declarative data into the shape I wanted - the data could just be output from a script. On the other hand I understand if having a Turing-complete language for configuration is a bad thing because of security or too much expressiveness that hinders static analysis because of unseen edge cases. It depends on if the "scripting" features are hacks intended to get around the fundamental limitations of DSLs or a deliberately constructed featureset. Also the reason I became so attached to declarative configs in the first place was the prospect of writing an editor frontend to interactively create new data entries. That's probably the reason Azure went with JSON instead of a programming language - they have a template editor in the web portal for filling in the parameterized variables the config declares. This is probably an ease-of-use tradeoff so people don't need to program to deploy things. As someone who uses scripts as configs, how to properly write an editor for them escapes me. I was thinking of having to parse the scripts into an AST and use heuristics to discover where data is inserted, but of course you can program anything so this won't always work. Still, in my opinion I would choose something like Lua any day over the nth domain-specific proprietary reimplementation of 2% of JavaScript on top of JSON. [1] https://github.com/SFTtech/nyan https://github.com/SFTtech/nyan

yachtman 7y ago

All these kinds of HN comments share the same flaw, in failing to recognize that the primary obsession of hacker news is in discussing the flaws of things posted on hacker news.

ajoy 7y ago
I would argue that thats the benefit. I want people more knowledgable than me to comment and point out the flaws in products/reports/theories. Thats what I love about HN. How critical are those flaws? It's up to you. If you take the approach of "there is no right or wrong, only opinions" when you read comments, it's much better off.
- plufz 7y ago
  I would argue that trying to find flaws is flawed (atleast in this context). Much better to use a neutral approach where you are equally open to strength and flaws.

threatofrain 7y ago

Using Ansible is what made me lose faith in DSL's in all the ways mentioned (eventually wanted loops, conditions, variables and namespaces...). Ansible is an API over a domain and if it were originally just represented through a Python language library I don't see why it would be less accessible or productive. Even something as simple as YAML can be screwed up and turned complicated.

alwillis 7y ago
Even though I know how to program, I really like Ansible and probably wouldn’t have gotten into it if it had the same functionality but used Python instead of YAML.
farisjarrah 7y ago
Building infrastructure is complicated. Have you found an easier way then Ansible to accomplish building infrastructure? Ansible does make yaml more complicated, however, you don't need to use much of that complexity for simple projects. Compared to Terraform, Chef, Google Deployment Manager, and Windows Desired State Configuration, Ansible is by far the simplest to get up and running on to do real work with.
- erikpukinskis 7y ago
  AWS CDK would be an example of using a programming language rather than a DSL to build infra.
  - ofrzeta 7y ago
    There's also Pulumi that covers a wider range of infrastructure than AWS only.
Middleclass 7y ago
Have you tried SaltStack? It uses YAML too, but always felt much more cleanly composed, and smoothly integrates with scripting languages. I've never truly broken into orchestration and am still salty about that so please, take my post with a grain of salt. (Full disclosure: I have literally no professional affiliations whatsoever.)
cryptonector 7y ago
> Even something as simple as YAML can be screwed up and turned complicated. Your problem is that you think YAML is simple.

erikpukinskis 7y ago

Some of us legitimately believe DSLs are rarely the right choice. We don’t say this to shit on people’s work, we say it to kick off a conversation about API design. I’ve written DSLs in the past. I was a Rubyist! I have come to some perspective on those choices in the intervening years. I’m a big fan of functions that take arguments, and I am skeptical of hidden shared state.

debaserab2 7y ago
You can be skeptical of DSL's but still recognize that they provide a time/complexity trade-off. I agree that it's probably not the right decision to write your own DSL for something but to dogmatically crusade against all DSL's feels silly to me when there are so many popular projects using them. Ansible is popular because it is accessible to devop type roles (previously known as sysadmin or IT services) that may know some programming but would fail to produce results nearly as fast if they were simply left with python libraries. It would not be as popular as it is today if it were simply a python library. Criticizing this project for using a DSL as it's interface over some programmer purity test BS is completely missing the forest for the trees.
- erikpukinskis 7y ago
  > they provide a time/complexity trade-off I think that’s too specific of a claim for such a broad category as DSLs. I think in specific cases there is a time-complexity tradeoff you can exploit, those are the (IMO extremely rare) cases where a DSL is worth considering. But in a lot of cases it’s just added complexity. Functions are pretty powerful. And they are also easier to reason about. Often the DSL adds “time” because you’re like “why the heck isn’t this working” and it’s because of some weird state you can’t inspect that’s deep inside your parse tree. “Guess I better start reading the source code of my DSL runtime. Oh look, someone hacked a corner care into the parser.” My rule of thumb would be something like: 1) if you have time to make your DSL superbly executed, and 2) you are very certain it can make an entire class of problems go away, and 3) you don’t expect weird corner cases to ever show up in a future project that break the model ...then it’s worth considering. As a professional coder though, I don’t see a lot of situations like that. In particular the “build this module superbly” is generally not an option on the table. Nor is “you can model the domain of future needs thoroughly” But I work at startups, I bet at a BigCo if you are a very senior person DSLs are on the table more often.

nonbirithm 7y ago

I tried using Ansible once and could never escape the fact that anything complex like installing files or raising docker containers requires the use of external modules with actual code and templated YAML. Every time something "templated" shows up in a supposedly "declarative" language it feels like the designers had to add on features from an actual programming language to do what they wanted, because the DSL was too declarative and static to accomplish anything useful. For example, look at this Azure deployment template: https://github.com/Azure/azure-quickstart-templates/blob/65d6fe33c1c1789ef13f4c3f94d0634de0b156d3/101-vm-simple-windows/azuredeploy.json#L54 https://github.com/Azure/azure-quickstart-templates/blob/65d... Notice all the inline function calls. They basically modified JSON with their own domain-specific "functions" like "concat" and have an entire section dedicated to "variables" because in standard JSON this is not possible to express. Already this sounds like a scripting language, except terribly watered down and specific only to Azure services. As a personal anecdote, I once made the dumb mistake of choosing a static config file instead of a dynamic one when I was developing a mod system for a game. The problem became that there were things like function callbacks that I wanted to add in, so that meant I ended up writing inline "pointers" to a place where a Lua callback existed as an identifier, instead of inlining it as Lua code, then it went through an unnecessary transpilation step to Lua data structures. My mistake was assuming that the DSL was expressive enough for my needs, which included loops, inline function callbacks and code generation, when clearly it was not. Sometimes the effort people expend to make declarative configs work out are significant. The OpenAge project (an engine rewrite of Age of Empires II) uses a declarative language called nyan[1] which describes the changes of things like unit health or cost. It's entirely custom-made for the engine. The moment that I realized that declarative configs were not for me was when I realized that this declarative language, which the author wrote an entire PhD thesis over and was specifically designed for the purpose of game modding, would still not be expressive for the things I was envisioning. In the end Lua, a general-purpose language that had existed for decades, was the better choice. There was no need to muck around with writing new languages or munging the declarative data into the shape I wanted - the data could just be output from a script. On the other hand I understand if having a Turing-complete language for configuration is a bad thing because of security or too much expressiveness that hinders static analysis because of unseen edge cases. It depends on if the "scripting" features are hacks intended to get around the fundamental limitations of DSLs or a deliberately constructed featureset. Also the reason I became so attached to declarative configs in the first place was the prospect of writing an editor frontend to interactively create new data entries. That's probably the reason Azure went with JSON instead of a programming language - they have a template editor in the web portal for filling in the parameterized variables the config declares. This is probably an ease-of-use tradeoff so people don't need to program to deploy things. As someone who uses scripts as configs, how to properly write an editor for them escapes me. I was thinking of having to parse the scripts into an AST and use heuristics to discover where data is inserted, but of course you can program anything so this won't always work. Still, in my opinion I would choose something like Lua any day over the nth domain-specific proprietary reimplementation of 2% of JavaScript on top of JSON. [1] https://github.com/SFTtech/nyan https://github.com/SFTtech/nyan