6 ms·

All those kind of projects share the same flaw: it uses a DSL instead of an existing language, so tooling/documentation/testing/support/modules are going to be

All those kind of projects share the same flaw: it uses a DSL instead of an existing language, so tooling/documentation/testing/support/modules are going to be very weak, and 100% depending of the creator for the first years, in a domain that is already a niche. It could be a library with good API instead. Or even a special env setup for an existing language with injected built-in and automatic imports. Now you could argue that the goal is to have this "simple DSL that looks like english" so that normal people can use it. This argument has existed since DSL exist, and the result is always the same: - the simplicity of the language will, in the end, limits its usefulness. Not every domain is like SQL/HTML/CSS, where descriptive is enough. Complex domains need branches, loop, namespaces, etc. Eventually you will be forced to add features in a twisted way to something that was not designed for it and replace its simplicity with ugliness, or restrain yourself and be limited forever. See Ansible DSL for a good, or rather, horrible, example of that. - end users that can't use a normal programming language won't suddenly become tech saavy because your DSL is simple, but their use case will never stop at simple. So they will start building complex systems as soon as they use it for real, with a limited DSL and their limited ability. The system will become a monstrosity, and you'll have no tooling to help. - successful dsl are usually not simple. Css is not. Sql is not. Html is an exception because it has no logic. This has logic. - it looks so cool. It's like candy for tech lovers. Even to me: I find it so sexy. And so people will adopt it, ignoring the arguments above. Ignoring the decades of such attempts that ended up in pain behind so many corporate firewalls. There will be many tweets at adoption to talk about how nice it is, but no blog post 2 years later to admit it was a bad idea. And then it will happen again with $new_shiny_dsl_based_tool.

KaoruAoiShiho 7y ago
The whole point of this is the scripting language, there are already lots of other browser automation tools out there.
- BiteCode_dev 7y ago
  A scripting language is not a goal in itself (although in the case of a DSL, it often is unfortunately because of the coolness factor), solving a problem is. Here the problems it tries to solve are: 1 - to have a nicer API to do automation 2 - for non tech saavy users to be able to create tests My take on this is that DSL are a wrong answer to this. 1 can be solved with a better lib, with a better API, or a dedicated env. 2 is probably not solvable: automatic testing it hard, you need to be tech saavy to do it. But let's say you still want to solve 2, a better approach would be to solve 1, then solve 2 by creating a GUI that let users record their actions and generate code from 1. Such API and GUI exist, as you said, but they could be improved by tenfold. It's boring work though, and working on a DSL is much more cool.
  - SlowRobotAhead 7y ago
    > A scripting language is not a goal in itself Agreed, I think this is a case where people forget “what is the problem I’m trying to solve” and instead get lost in a means not an ends.
    - exdsq 7y ago
      Depends if the goal was to make a scripting language and at the same time tackle a problem (or not). Some people like building stuff for the hell of it. A language by itself is an interesting non-trivial project.
swalsh 7y ago
I actually kind of really like this DSL, I think it is going to be easier for my QA team to use this, than asking them to use javascript.
- BiteCode_dev 7y ago
  I know right. It looks so nice. I want to pet it. But it's a trap.
- amitport 7y ago
  Seriously, how is this DSL better? With JavaScript you get method completion and debugging. Are parentheses really so terrible? You can setup a DSL in scala.js and you can get the best of both worlds (though, parentheses are fine for me so I would just use one of the many fine existing JS libraries).
  - masukomi 7y ago
    > With JavaScript you get method completion and debugging. a) now your QA team needs to know JavaScript b) method completion is crap when you don't know the language. c) "You can setup a DSL in scala.js and you can get the best of both worlds" OMG You want to add Scala to the mix too? AND write your own DSL from scratch, and take on its maintenance to support your QA team's needs instead of leveraging an existing one? your solution: 1. teach the QA team Javascript interaction with custom scala created dsl 2. have the dev team spend time creating a dsl 3. have the dev team devote some of its resources to maintaining the new DSL their solution: 1. use english-like DSL much easier to learn than JS 2. that is already created 3. that someone else maintains both solutions are going to have limitations in that what you want the DSL to do will be more than the DSL can _currently_ do.
    - holtalanm 7y ago
      1) if you are on a qa team writing automation, there is a high chance you already know javascript. source: was qa automation engineer for a few years. I realize it is purely anecdotal, but nearly all of the QA people I worked with knew javascript, even the manual testers.
debaserab2 7y ago
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.
pankajdoharey 7y ago
Absolutely the current version seems very limiting, but as they start adding more and more features towards Turing completeness, it will become just as complex as a normal Turing complete programming language. Which in many ways undermines the original promise.
brutuz 7y ago
These are actually valid points for any DSL creation. I have been working on DSL for a few years. More precisely I'm working on a DSL tool that allows people to create "simple DSL that looks like english" so that normal people can use it. Here are my thoughts on those arguments. Indeed complexity is there for most real domains. But DSL is meant to be another abstraction layer on top of the complexity. My lesson is constraint is the most important as this lays the foundation of its usefulness. I don't mean you should not have things like branch or loop. You certainly could add them, just in a domain friendly way that doesn't hurt the readability and writability of your DSL. In order to tackle arbitrary complexity, the DSL itself should be designed with extensibility in mind so that technical people could easily add language constructs or vocabularies by using script or general purpose language. Further, those features should be able to be turned off for some scenarios. For those inherently complex stuff, they should be left to general purpose language anyway. Tooling support is another big problem. In my opinion, DSL is never just the tiny language, it is about the language and tooling. However the tooling requirement is often not as standard as general purpose language. Domain users normally don't need an IDE(an editor should be generally required) or debugger. Rather, they want something that can be seamlessly integrated with the host application. And more over, different people (even in the same domain) may have different requirements on DSL maintenance, eg, governance, versioning. This often leads to a case by case customization. I do not have a good answer for this other than the general advice: treat DSL and tooling as a whole and make the API as easy as possible for integration. Edit: For anyone interested in my DSL(still work in progress), here is a glimpse: http://www.typezoo.com/docs/workflowrules/editor-2.gif http://www.typezoo.com/docs/workflowrules/editor-2.gif

KaoruAoiShiho 7y ago

The whole point of this is the scripting language, there are already lots of other browser automation tools out there.

BiteCode_dev 7y ago
A scripting language is not a goal in itself (although in the case of a DSL, it often is unfortunately because of the coolness factor), solving a problem is. Here the problems it tries to solve are: 1 - to have a nicer API to do automation 2 - for non tech saavy users to be able to create tests My take on this is that DSL are a wrong answer to this. 1 can be solved with a better lib, with a better API, or a dedicated env. 2 is probably not solvable: automatic testing it hard, you need to be tech saavy to do it. But let's say you still want to solve 2, a better approach would be to solve 1, then solve 2 by creating a GUI that let users record their actions and generate code from 1. Such API and GUI exist, as you said, but they could be improved by tenfold. It's boring work though, and working on a DSL is much more cool.
- SlowRobotAhead 7y ago
  > A scripting language is not a goal in itself Agreed, I think this is a case where people forget “what is the problem I’m trying to solve” and instead get lost in a means not an ends.
  - exdsq 7y ago
    Depends if the goal was to make a scripting language and at the same time tackle a problem (or not). Some people like building stuff for the hell of it. A language by itself is an interesting non-trivial project.

swalsh 7y ago

I actually kind of really like this DSL, I think it is going to be easier for my QA team to use this, than asking them to use javascript.

BiteCode_dev 7y ago
I know right. It looks so nice. I want to pet it. But it's a trap.
amitport 7y ago
Seriously, how is this DSL better? With JavaScript you get method completion and debugging. Are parentheses really so terrible? You can setup a DSL in scala.js and you can get the best of both worlds (though, parentheses are fine for me so I would just use one of the many fine existing JS libraries).
- masukomi 7y ago
  > With JavaScript you get method completion and debugging. a) now your QA team needs to know JavaScript b) method completion is crap when you don't know the language. c) "You can setup a DSL in scala.js and you can get the best of both worlds" OMG You want to add Scala to the mix too? AND write your own DSL from scratch, and take on its maintenance to support your QA team's needs instead of leveraging an existing one? your solution: 1. teach the QA team Javascript interaction with custom scala created dsl 2. have the dev team spend time creating a dsl 3. have the dev team devote some of its resources to maintaining the new DSL their solution: 1. use english-like DSL much easier to learn than JS 2. that is already created 3. that someone else maintains both solutions are going to have limitations in that what you want the DSL to do will be more than the DSL can _currently_ do.
  - holtalanm 7y ago
    1) if you are on a qa team writing automation, there is a high chance you already know javascript. source: was qa automation engineer for a few years. I realize it is purely anecdotal, but nearly all of the QA people I worked with knew javascript, even the manual testers.

debaserab2 7y ago

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.

pankajdoharey 7y ago

Absolutely the current version seems very limiting, but as they start adding more and more features towards Turing completeness, it will become just as complex as a normal Turing complete programming language. Which in many ways undermines the original promise.

brutuz 7y ago

These are actually valid points for any DSL creation. I have been working on DSL for a few years. More precisely I'm working on a DSL tool that allows people to create "simple DSL that looks like english" so that normal people can use it. Here are my thoughts on those arguments. Indeed complexity is there for most real domains. But DSL is meant to be another abstraction layer on top of the complexity. My lesson is constraint is the most important as this lays the foundation of its usefulness. I don't mean you should not have things like branch or loop. You certainly could add them, just in a domain friendly way that doesn't hurt the readability and writability of your DSL. In order to tackle arbitrary complexity, the DSL itself should be designed with extensibility in mind so that technical people could easily add language constructs or vocabularies by using script or general purpose language. Further, those features should be able to be turned off for some scenarios. For those inherently complex stuff, they should be left to general purpose language anyway. Tooling support is another big problem. In my opinion, DSL is never just the tiny language, it is about the language and tooling. However the tooling requirement is often not as standard as general purpose language. Domain users normally don't need an IDE(an editor should be generally required) or debugger. Rather, they want something that can be seamlessly integrated with the host application. And more over, different people (even in the same domain) may have different requirements on DSL maintenance, eg, governance, versioning. This often leads to a case by case customization. I do not have a good answer for this other than the general advice: treat DSL and tooling as a whole and make the API as easy as possible for integration. Edit: For anyone interested in my DSL(still work in progress), here is a glimpse: http://www.typezoo.com/docs/workflowrules/editor-2.gif http://www.typezoo.com/docs/workflowrules/editor-2.gif